On 7/16/2019 7:03 AM, Serge E. Hallyn wrote: > 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. I shake my head and sigh, but as I don't have a better solution, nor the time to go looking for one, I'm not going to place obstacles. That, and it's entirely possible that my view is wrong. > > -serge
