The libcap-1.10/doc/capability.notes file says it's more secure for root to not own any files on the system. It suggests having a 'system' user, who never logs in, owning everything that root would normally own. This is true to an extent...
If Linux capabilities for a root process are dropped so the process does not have CAP_FOWNER or CAP_FSETID (previously this was CAP_FUSER) capabilities, the root owned process won't be able to modify/delete, or change ownership, on files that root doesn't own. If root owns everything, then dropping these capabilities is useless. The sticky-bit on directories helps with this too. This is helpfull in certain suid applications... like /bin/ping, which is suid so it can send out raw packets. If /bin/ping drops capabilities when it starts, it can still be root but wouldn't have the ability to modify non-root files. Now that I think of it, /bin/ping could also run in a chroot, but that's another topic. It looks like the 'execcap' utility, from libcap-1.10, can be used on /bin/ping without any modification to ping's source code, except maybe linking ping to libcap. Alternatively, ext2/3 filesystem attributes can set this too. As far as I know, Grsecurity/Selinux role based access control works independently of Linux capabilities, so they can both be used at the same time. robert
pgpRJRZqJmi6x.pgp
Description: PGP signature
-- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
