On Mon, Jul 27, 2009 at 5:29 PM, Adam Jackson<ajax@xxxxxxxxxx> 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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
