From: Stephen Smalley <sds@tycho.nsa.gov>
To: Andy Lutomirski <luto@kernel.org>, "Serge E. Hallyn" <serge@hallyn.com>
Cc: Casey Schaufler <casey@schaufler-ca.com>,
Nicholas Franck <nhfran2@tycho.nsa.gov>,
Paul Moore <paul@paul-moore.com>,
selinux@vger.kernel.org,
LSM List <linux-security-module@vger.kernel.org>,
James Morris <jmorris@namei.org>,
Kees Cook <keescook@chromium.org>,
John Johansen <john.johansen@canonical.com>,
mortonm@chromium.org
Subject: Re: [RFC PATCH] security, capability: pass object information to security_capable
Date: Tue, 16 Jul 2019 11:08:21 -0400 [thread overview]
Message-ID: <38ae330f-d673-d01b-c2be-530f9668ced5@tycho.nsa.gov> (raw)
In-Reply-To: <CALCETrXR3RoRF0kZk_G-gAg=D6LNAcBJYiiHFHSe3S=bRZcwNA@mail.gmail.com>
On 7/16/19 10:21 AM, Andy Lutomirski wrote:
> On Tue, Jul 16, 2019 at 7:03 AM Serge E. Hallyn <serge@hallyn.com> 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.
>
> Agreed. The concept in the kernel is "capability over a namespace."
>
> That being said, sticking a flexible object type into ns_capable()
> seems prematurely general to me. How about adding
> security_capable_wrt_inode_uidgid() and allowing LSMs to hook that?
> The current implementation would go into commoncap. The obvious
> extensions I can think of are security_dac_read_search(..., inode,
> ...) and security_dac_override(..., inode, ...). (Or dentry or
> whatever is appropriate.)
1) Not even all the inode-related capability checks go through
capable_wrt_inode_uidgid(), so a hook there won't suffice.
2) Other capabilities have other kinds of objects, e.g. tasks, sysvipc,
etc, and we'll want those to be handled too.
>
> If this patch were restructured like that, the semantics would be
> obvious, and it would arguably be a genuine cleanup instead of a whole
> new mechanism of unknown scope.
>
next prev parent reply other threads:[~2019-07-16 15:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-12 17:34 [RFC PATCH] security,capability: pass object information to security_capable Nicholas Franck
2019-07-12 17:50 ` James Morris
2019-07-12 18:02 ` [RFC PATCH] security, capability: " Stephen Smalley
2019-07-15 18:42 ` Richard Guy Briggs
2019-07-12 17:58 ` [RFC PATCH] security,capability: " Casey Schaufler
2019-07-12 18:25 ` [RFC PATCH] security, capability: " Stephen Smalley
2019-07-12 19:54 ` Casey Schaufler
2019-07-12 20:21 ` Stephen Smalley
2019-07-12 22:37 ` Casey Schaufler
2019-07-13 4:35 ` James Morris
2019-07-13 18:46 ` Casey Schaufler
2019-07-13 4:29 ` James Morris
2019-07-16 14:03 ` Serge E. Hallyn
2019-07-16 14:21 ` Andy Lutomirski
2019-07-16 15:03 ` Casey Schaufler
2019-07-16 15:08 ` Stephen Smalley [this message]
2019-07-16 14:43 ` Casey Schaufler
2019-07-24 20:12 ` Paul Moore
2019-07-16 14:16 ` [RFC PATCH] security,capability: " Serge E. Hallyn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=38ae330f-d673-d01b-c2be-530f9668ced5@tycho.nsa.gov \
--to=sds@tycho.nsa.gov \
--cc=casey@schaufler-ca.com \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=keescook@chromium.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mortonm@chromium.org \
--cc=nhfran2@tycho.nsa.gov \
--cc=paul@paul-moore.com \
--cc=selinux@vger.kernel.org \
--cc=serge@hallyn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).