[RFC PATCH] security, capability: pass object information to security_capable

[Casey Schaufler]

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