Lower Process Capabilities

[Adam Jackson]

On Mon, 2009-07-27 at 19:25 +1000, James Morris wrote:
> On Sun, 26 Jul 2009, Steve Grubb wrote:
> > The basic idea goes something like this: We would like to do something to 
> > prevent priv escalation for processes running as root. For this example, lets 
> > take cupsd to be a good case in point. If the attacker can find a vuln with 
> > cupsd, then they can have root privs and all that goes with it. (SE Linux may 
> > prevent total compromise, but some people turn it off.)
> 
> We should put effort into improving SELinux rather than papering things 
> over with new or previously discarded security schemes.
> 
> Capabilities are inherently problematic in that you can't meaningfully 
> reason about overall system behavior with them.
> 
> e.g. what does CAP_SYS_ADMIN actually mean?
> 
> Here's where the symbol is found in the kernel source:
> http://www.cs.fsu.edu/~baker/devices/lxr/http/ident?i=CAP_SYS_ADMIN
> 
> I challenge anyone to explain the boundary of privilege for any process 
> which has this capability, and how the propagation of that privilege is 
> bounded within the system as a whole.
> 
> We can do that with SELinux (in fact it's been somehwat designed for this 
> purpose), and that's how we should approach the problem.

I agree with this, with some caveats.

Capabilities are hard to reason about, and not just because they're
coarse-grained.  Practically speaking they don't get used, so kernel
developers are careless about picking the right capable() check for a
given action, since it ends up being a fancy way of checking
current->euid.

To pick a favorite example: CAP_SYS_RAWIO is documented to mean "iopl,
ioperm, and /dev/kcore".  It actually means significantly more than
that.  It's effectively equivalent to root, though, because write access
to /dev/kcore means you can change your uid.  You might like it to mean
"can do raw I/O to peripherals" like the name suggests, but the one most
useful thing that could mean - r/w maps of PCI BARs - is covered under
CAP_SYS_ADMIN instead.  Which is not merely equivalent to root, but so
coarse that it's basically useless.  So it's hard for me to justify
trying to make X use capabilities, since I'm not meaningfully limiting
X's privileges in doing so.

Caps are also wrong in that they're effectively a partitioning of root's
privileges above those of a user.  You would like the ability to do more
than that.  For example, you'd like to be able to remove your ability to
clone() or exec().  SELinux can do this, kinda.

And, of course, at an implementation level caps are just a dword
bitmask, which is not nearly enough granularity.

However, the inheritance model is _not_ hard to reason about.  I find it
slightly easier to understand than selinux transitions, in fact.  And
capabilities have the notable advantage of being something I can drop
for myself when I don't need them, a safety model I'm used to from
setuid.  I would like to use SELinux as a defensive development
practice, but I'm not aware of any good way to do so.  All I have is the
hope that the user is running with the policy enabled.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20090727/43422907/attachment.bin