[Mod: The to address has been changed. The original message has been CC'ed
to linux-security. This is mostly FYI only -- alex]
Winfried,
Good question. Since Linux-2.2.* has hit the streets, I'm guessing there
may be wider interest in this sort of thing so I'm CC'ing my reply to
linux-security.
The capability stuff in the kernel provides a way to strip away all of
the privilege that the superuser usually holds. Using the execcap
program, you do indeed prevent the root-user from getting around the
sticky bit... (This is what you observe happenning when, as 'root', you
fail to delete the file in your home directory.)
The reason root is still able to delete the /tmp/ file and not the
/home/wini/ file is because root owns the /tmp/ directory. Take a look
at the function check_sticky() in linux/fs/namei.c. You'll see that
there is a check to see if the owner of the directory is the user trying
to do the deed. If so, the sys_unlink() succeeds.
For the security paranoid: all system files/directories should be owned
by some user with no login account: 'adm' or 'system' might be a
good
choice. Thus, any legitimate (capable) instance of the superuser can
still maintain/manipulate the system, but any rougue daemon (hobbled
with a wrapper like execcap, but running as root because of a need for a
restricted number of capabilities) cannot start replacing system
libraries etc.
[There is a small book called Secure Unix by Samuel Samalin which goes
into this sort of thing. It gives a broarder perspective on what the
future of UNIX was going to be -- it seemed to be aimed at introducing
the concepts that the now defunct POSIX-security group were laboring
over throughout this decade. Its really aimed at manager types, but its
certainly worth a browse in the bookshop...]
Hope this helps
Cheers
Andrew
PS. For anyone watching, you can get the libcap library and sample
programs with all the manual pages here:
ftp://linux.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/
Winfried Truemper wrote:>
> Hi Andrew,
>
> maybe I misunderstand the concept of capabilities, but if root drops all
> his capabilities (see below), should he still be able to delete other
> users files in /tmp (and other directories with the t-bit applied)?
>
> Here is, what I did: remove a file owned by winni in /tmp and in
> /home/winni. First succeeds, last gives a permission denied.
>
> # execcap CAP_NET_BIND_SERVICE=ip rm /tmp/winni.txt
> rm: remove `/tmp/winni.txt', overriding mode 0664? y
> # dir /tmp/winni.txt
> ls: /tmp/winni.txt: No such file or directory
> # execcap CAP_NET_BIND_SERVICE=ip rm ~winni/winni.txt
> rm: remove `/home/winni/winni.txt', overriding mode 0664? y
> rm: /home/winni/winni.txt: Permission denied
> # dir -d /tmp
> lrwxrwxrwx 1 root root 7 Dec 21 12:31 /tmp -> var/tmp
> # dir -d /var/tmp/
> drwxrwxrwt 5 root root 1024 Jan 29 20:36 /var/tmp/
>
> Regards
> -Winfried
