Lower Process Capabilities

yersinia yersinia.spiros at gmail.com
Mon Jul 27 23:12:59 UTC 2009


On Mon, Jul 27, 2009 at 5:29 PM, Adam Jackson<ajax at redhat.com> wrote:
> 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.

Put an example, thanks.
>
> 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
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>




More information about the fedora-devel-list mailing list