On Fri, Jul 12, 2019 at 12:54:02PM -0700, Casey Schaufler wrote: > On 7/12/2019 11:25 AM, Stephen Smalley wrote: > > On 7/12/19 1:58 PM, Casey Schaufler wrote: > >> On 7/12/2019 10:34 AM, Nicholas Franck wrote: > >>> At present security_capable does not pass any object information > >>> and therefore can neither audit the particular object nor take it > >>> into account. Augment the security_capable interface to support > >>> passing supplementary data. Use this facility initially to convey > >>> the inode for capability checks relevant to inodes. This only > >>> addresses capable_wrt_inode_uidgid calls; other capability checks > >>> relevant to inodes will be addressed in subsequent changes. In the > >>> future, this will be further extended to pass object information for > >>> other capability checks such as the target task for CAP_KILL. > >> > >> This seems wrong to me. The capability system has nothing to do > >> with objects. Passing object information through security_capable() > >> may be convenient, but isn't relevant to the purpose of the interface. > >> It appears that there are very few places where the object information > >> is actually useful. > > > > A fair number of capabilities are checked upon some attempted object access (often right after comparing UIDs or other per-object state), and the particular object can be very helpful in both audit and in access control. More below. > > I'm not disagreeing with that. What I'm saying is that the capability > check interface is not the right place to pass that information. The > capability check has no use for the object information. I would much I've had to argue this before while doing the namespaced file capabilities implementation. Perhaps this would be worth writing something more formal about. My main argument is, even if we want to claim that the capabilities model is and should be object agnostic, the implementation of user namespaces (currently) is such that the whole view of the user's privilege must include information which is stored with the object. There are various user namespaces. The Linux capabilities ( :-) ) model is user namespaced. It must be, in order to be useful. If we're going to use file capabilities in distros, and distros are going to run in containers, then the capabilities must be namespaced. Otherwise, capabilities will not be used, and heck, should just be dropped. The only way to find out which user namespace has privilege over an inode is to look at the inode. Therefore, object information is needed. Until now we've sneaked around that by doing things like capable_wrt_inode_uidgid() and rootid_from_xattr(). Again, this crucial: IMO, you have to be able to use a distro the same way in a container and not. Either we support using capabilities in a user namespaced container, or we drop capabilities support will not be used, and we may as well drop the module. Now, yes, if someone tries to extend this stuff to do pathname parsing, then we might have to put our footsies down. But we've been dancing around this for a long time anyway, so passing the inode in so we can do better logging gets a +1 from me. -serge
