Designing better kernel ABIs [LWN.net]

Designing better kernel ABIs

Posted Oct 27, 2016 13:17 UTC (Thu) by mkerrisk (subscriber, #1978)
In reply to: Designing better kernel ABIs by bandrami
Parent article: Designing better kernel ABIs

Because there are something 1500 different capability checks in the kernel. We need to have silos of similar operations, rather than one capability for each check. Plus, the capability masks attached to files are currently 64 bits in size, of which 38 are so far used. Plus, having vast numbers of capabilities would make the life of sysadmins painful, in terms of trying to have a manageable grasp on what is going on on their system.

to post comments

Designing better kernel ABIs

Posted Oct 27, 2016 13:27 UTC (Thu) by bandrami (guest, #94229) [Link] (2 responses)

Huh. From a design point I would assume making those silos is what my job as a sysadmin should be (though then again I generally disable capabilities and acls because they make security reasoning more complex than I like). I get the bitmask limit (I had thought it was 512 for some reason), but when I do use capabilities I always get worried about SYS_ADMIN and SETPCAP because from what I can see I might as well just be granting that process root at that point.

Designing better kernel ABIs

Posted Oct 27, 2016 15:46 UTC (Thu) by nybble41 (subscriber, #55106) [Link] (1 responses)

> ... when I do use capabilities I always get worried about SYS_ADMIN and SETPCAP because from what I can see I might as well just be granting that process root at that point.

While fine access control granularity is generally a good thing, a number of capabilities are effectively equivalent to root or can be leveraged to obtain root given typical system configurations[1]. I see no reason why these should not be covered by a single CAP_SYS_ADMIN bit, reserving the remaining bits for those capabilities which can actually be isolated and contained.

[1] https://forums.grsecurity.net/viewtopic.php?f=7&t=2522 (Summary: 19 of the 35 capabilities then present were considered equivalent to being granted root access.)

Designing better kernel ABIs

Posted Oct 28, 2016 4:39 UTC (Fri) by mkerrisk (subscriber, #1978) [Link]

>> ... when I do use capabilities I always get worried
>> about SYS_ADMIN and SETPCAP because from what
>> I can see I might as well just be granting that
>> process root at that point.

(Yes, this issue one that I wrote about in an article linked to from the current article.)

> While fine access control granularity is generally a
> good thing, a number of capabilities are effectively equivalent
> to root or can be leveraged to obtain root given typical system
> configurations[1].

Yes, some capabilities can be leveraged to full root, but that doesn't necessarily make the scheme useless: the attacker still has to be able to execute the pathway that leverages to full root, so capabilities at least made the attacker's job harder.

> I see no reason why these should not be
> covered by a single CAP_SYS_ADMIN bit, reserving the
> remaining bits for those capabilities which can actually be
> isolated and contained.

The fundamental problem here is that by expanding CAP_SYS_ADMIN we exacerbate the existing problem that that capability really is as good (from an attacker's point of view) as traditional root. In fact, looking at the capabilities(7) man page to the (very partial) list of features enabled by CAP_SYS_ADMIN, there's a good argument that some of those could, and should, have been isolated out into some other silo, possibbly a new silo (capability) or a one of the existing silos. Here's a few cases that seem obvious to me:

              * perform IPC_SET and IPC_RMID operations on arbitrary Sys‐
                tem V IPC objects;
              * use ioprio_set(2) to assign IOPRIO_CLASS_RT  and  (before
                Linux 2.6.25) IOPRIO_CLASS_IDLE I/O scheduling classes;
              * employ CLONE_* flags  that  create  new  namespaces  with
                clone(2)  and  unshare(2) (but, since Linux 3.8, creating
                user namespaces does not require any capability);
              * call perf_event_open(2);
              * access privileged perf event information;
              * call  setns(2)  (requires  CAP_SYS_ADMIN  in  the  target
                namespace);