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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
