Re: using capabilities to allow debug of suid-root programs (ptrace not allowed even after dropping
Andrew Morgan (morgan@transmeta.com)
Sat, 17 Apr 1999 11:24:32 -0700
peeterj@ca.ibm.com wrote:
>
> [pjoot@openfire cap]$ ./debugwrap touch /blah
> [pjoot@openfire cap]$ ls -l /blah
> -rw-r--r-- 1 root build 0 Apr 17 13:24 /blah
> [pjoot@openfire cap]$ ./debugwrap rm /blah
> [pjoot@openfire cap]$ ls -l /blah
> ls: /blah: No such file or directory
>
> This seems no different then a plain old suid root program. I tried
> setreuid(getuid(), getuid()) before the exec (and after the cap_set_proc),
> but this clears other capabilities at the same time. I thought that the
> whole idea of this capability stuff is so that the entire set of root
> capabilities isn't explicitly inherited, but this appears to be what is
> happening? Is the problem that ext2, or some other part of the kernel is
> just not respecting the capabilities flags properly, and is unconditionally
> doing the open which creates the file /blah when it sees the uid is 0?
Remember, capabilities are only available (by default) for root to make
use of. But root has a real account, so a setuid-root program can
legitimately manipulate root-owned files even without any capabilities.
Example, try this:
[pjoot@openfire cap]$ touch /blah
[pjoot@openfire cap]$ ls -l /blah
-rw-r--r-- 1 pjoot build 0 Apr 17 13:24 /blah
[pjoot@openfire cap]$ ./debugwrap rm /blah
Unless root happens to own the cap directory, I believe you'll have some
trouble deleting the file.
Cheers
Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/