system file ownership

Robert Connolly robert at linuxfromscratch.org
Sun Jun 3 16:31:14 PDT 2007


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20070603/418a60b2/attachment.sig>


More information about the hlfs-dev mailing list