CAP_SYS_ADMIN: the new root [LWN.net]

CAP_SYS_ADMIN: the new root

Posted Mar 14, 2012 18:15 UTC (Wed) by tialaramex (subscriber, #21167)
Parent article: CAP_SYS_ADMIN: the new root

Splitting privileges that are each equal to root into their own capability doesn't seem to achieve much, at least from a security point of view. Forty capabilities that are root equivalent isn't better than ten, or indeed one.

So it seems the main target should be those privileges or groups of privileges controlled by CAP_SYS_ADMIN which, after thorough examination, are useful separately without being root-equivalent in common systems. These could be given a new capability bit or added to an appropriate existing one.

Doing that "thorough examination" first is necessary I think, particularly for capabilities that already exist. Mistakenly adding some root-equivalent privilege to a capability because it "looked appropriate" superficially would be almost as bad as accidentally removing the capability checks from something vital. Having a new privilege temporarily in the CAP_SYS_ADMIN catch-all is much less awful.

Of course as with any bug, exactly how much a capability buys you will vary from one system to another. Snooping old-fashioned telnet was usually a goldmine. Snooping SSH is much less so (but far from completely useless). On some systems reading /etc/shadow is a big coup, on others not so much (e.g. there may be nothing in there but a (hash of the) local root password which can only be used on a physical console...). For this reason I don't much like Brad's classification of some escalations as "generic" but the idea of figuring out what attackers _might_ do with a privilege is definitely something to be left to white or grey hats and not the people doing routine Linux kernel development.

(Log in to post comments)

CAP_SYS_ADMIN: the new root

Posted Mar 15, 2012 2:54 UTC (Thu) by lutchann (subscriber, #8872) [Link]

> Mistakenly adding some root-equivalent privilege to a capability because it "looked appropriate" superficially would be almost as bad as accidentally removing the capability checks from something vital.

Yes, exactly. I don't want to have to grep every new kernel for CAP_.* to see if my containers are suddenly going to gain privileges that I didn't want them to have. I'm much happier with everything new going under CAP_SYS_ADMIN, which is already widely known to be a root equivalent.

CAP_SYS_ADMIN: the new BKL (;-))

Posted Mar 15, 2012 15:21 UTC (Thu) by davecb (subscriber, #1574) [Link]

I suspect we need to treat CAP_SYS_ADMIN the same way as we did the big kernel lock: carefully break it up into the small locks that we actually needed, and create a mechanism for allowing drivers to be kept in sync with specific locks they needed.

This is harder when one is breaking up a "lock" that is accessible from user-land, but once we've paid the price of no longer having the equivalent of the BKL, it gets *way* easier.

If asked, I can write a rant on how we migrating an equivalent problem out of existence for the GCOS C compiler (;-))

--dave

CAP_SYS_ADMIN: the new root

Posted Mar 17, 2012 17:55 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

Splitting privileges that are each equal to root into their own capability doesn't seem to achieve much, at least from a security point of view.

I agree, but the non-security point of view is also important, which is why I like the present situation.

I use capabilities mainly to prevent a process from accidentally exercising privilege I never meant it to have. For example, it's extremely useful to have a process forbidden to update a file owned by someone else even if the process has the ability to change its UID to the owner's.

CAP_SYS_ADMIN: the new root

Posted Mar 22, 2012 9:11 UTC (Thu) by kevinm (guest, #69913) [Link]

Absolutely agreed.

There will always be many operations which fundamentally are equivalent to root, because they can be used to subvert the kernel itself. Splitting these dangerous operations up into many different capabilities is counter-productive - they should all be under one "root-equivalent" capability. It doesn't much matter whether you call that capability CAP_SYS_ADMIN, CAP_RAWIO or CAP_AS_GOOD_AS_ROOT.