Linux Security Modules development
 help / color / mirror / Atom feed
From: Stephen Smalley <sds@tycho.nsa.gov>
To: Paul Moore <paul@paul-moore.com>
Cc: selinux@vger.kernel.org, will@kernel.org,
	viro@zeniv.linux.org.uk, neilb@suse.de,
	linux-fsdevel@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] selinux: fall back to ref-walk upon LSM_AUDIT_DATA_DENTRY too
Date: Fri, 22 Nov 2019 08:50:25 -0500	[thread overview]
Message-ID: <f18bee29-7634-606b-e58b-62049a193d5b@tycho.nsa.gov> (raw)
In-Reply-To: <9d825be2-c3ae-f4ad-9f82-adce7e2059d7@tycho.nsa.gov>

On 11/22/19 8:37 AM, Stephen Smalley wrote:
> On 11/21/19 7:30 PM, Paul Moore wrote:
>> On Thu, Nov 21, 2019 at 7:12 PM Paul Moore <paul@paul-moore.com> wrote:
>>> On Thu, Nov 21, 2019 at 9:52 AM Stephen Smalley <sds@tycho.nsa.gov> 
>>> wrote:
>>>> commit bda0be7ad994 ("security: make inode_follow_link RCU-walk aware")
>>>> passed down the rcu flag to the SELinux AVC, but failed to adjust the
>>>> test in slow_avc_audit() to also return -ECHILD on 
>>>> LSM_AUDIT_DATA_DENTRY.
>>>> Previously, we only returned -ECHILD if generating an audit record with
>>>> LSM_AUDIT_DATA_INODE since this was only relevant from 
>>>> inode_permission.
>>>> Return -ECHILD on either LSM_AUDIT_DATA_INODE or LSM_AUDIT_DATA_DENTRY.
>>>> LSM_AUDIT_DATA_INODE only requires this handling due to the fact
>>>> that dump_common_audit_data() calls d_find_alias() and collects the
>>>> dname from the result if any.
>>>> Other cases that might require similar treatment in the future are
>>>> LSM_AUDIT_DATA_PATH and LSM_AUDIT_DATA_FILE if any hook that takes
>>>> a path or file is called under RCU-walk.
>>>>
>>>> Fixes: bda0be7ad994 ("security: make inode_follow_link RCU-walk aware")
>>>> Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
>>>> ---
>>>>   security/selinux/avc.c | 3 ++-
>>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/security/selinux/avc.c b/security/selinux/avc.c
>>>> index 74c43ebe34bb..f1fa1072230c 100644
>>>> --- a/security/selinux/avc.c
>>>> +++ b/security/selinux/avc.c
>>>> @@ -779,7 +779,8 @@ noinline int slow_avc_audit(struct selinux_state 
>>>> *state,
>>>>           * during retry. However this is logically just as if the 
>>>> operation
>>>>           * happened a little later.
>>>>           */
>>>> -       if ((a->type == LSM_AUDIT_DATA_INODE) &&
>>>> +       if ((a->type == LSM_AUDIT_DATA_INODE ||
>>>> +            a->type == LSM_AUDIT_DATA_DENTRY) &&
>>>>              (flags & MAY_NOT_BLOCK))
>>>>                  return -ECHILD;
>>
>> With LSM_AUDIT_DATA_INODE we eventually end up calling d_find_alias()
>> in dump_common_audit_data() which could block, which is bad, that I
>> understand.  However, looking at LSM_AUDIT_DATA_DENTRY I'm less clear
>> on why that is bad?  It makes a few audit_log*() calls and one call to
>> d_backing_inode() which is non-blocking and trivial.
>>
>> What am I missing?
> 
> For those who haven't, you may wish to also read the earlier thread here 
> that led to this one:
> https://lore.kernel.org/selinux/20191119184057.14961-1-will@kernel.org/T/#t
> 
> AFAIK, neither the LSM_AUDIT_DATA_INODE nor the LSM_AUDIT_DATA_DENTRY 
> case truly block (d_find_alias does not block AFAICT, nor should 
> audit_log* as long as we use audit_log_start with GFP_ATOMIC or 
> GFP_NOWAIT). My impression from the comment in slow_avc_audit() is that 
> the issue is not really about blocking but rather about the inability to 
> safely dereference the dentry->d_name during RCU walk, which is 
> something that can occur under LSM_AUDIT_DATA_INODE or _DENTRY (or _PATH 
> or _FILE, but neither of the latter two are currently used from the two 
> hooks that are called during RCU walk, inode_permission and 
> inode_follow_link).  Originally _PATH, _DENTRY, and _INODE were all 
> under a single _FS type and the original test in slow_avc_audit() was 
> against LSM_AUDIT_DATA_FS before the split.
> 
>>
>>> Added the LSM list as I'm beginning to wonder if we should push this
>>> logic down into common_lsm_audit(), this problem around blocking
>>> shouldn't be SELinux specific.
> 
> That would require passing down the MAY_NOT_BLOCK flag or a rcu bool to 
> common_lsm_audit() just so that it could immediately return if that is 
> set and a->type is _INODE or _DENTRY (or _PATH or _FILE).  And the 
> individual security module still needs to have its own handling of 
> MAY_NOT_BLOCK/rcu for its own processing, so it won't free the security 
> module authors from thinking about it.  This is only relevant for 
> modules implementing the inode_permission and/or inode_follow_link 
> hooks, so it only currently affects SELinux and Smack, and Smack only 
> presently implements inode_permission and always returns -ECHILD if 
> MAY_NOT_BLOCK (aside from a couple trivial cases), so it will never 
> reach common_lsm_audit() in that case.

This would also require changing common_lsm_audit() to be able to return 
errors so that it can return -ECHILD and updating all callers to handle 
that.

> 
> 
>>>
>>> For the LSM folks just joining, the full patchset can be found here:
>>> * 
>>> https://lore.kernel.org/selinux/20191121145245.8637-1-sds@tycho.nsa.gov/T/#t 
>>>


  reply	other threads:[~2019-11-22 13:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20191121145245.8637-1-sds@tycho.nsa.gov>
     [not found] ` <20191121145245.8637-2-sds@tycho.nsa.gov>
2019-11-22  0:12   ` [RFC PATCH 2/2] selinux: fall back to ref-walk upon LSM_AUDIT_DATA_DENTRY too Paul Moore
2019-11-22  0:30     ` Paul Moore
2019-11-22 13:37       ` Stephen Smalley
2019-11-22 13:50         ` Stephen Smalley [this message]
2019-11-22 14:49         ` Paul Moore
2019-11-22 15:09           ` Stephen Smalley
2019-11-22 17:04             ` Stephen Smalley

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=f18bee29-7634-606b-e58b-62049a193d5b@tycho.nsa.gov \
    --to=sds@tycho.nsa.gov \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=paul@paul-moore.com \
    --cc=selinux@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will@kernel.org \
    /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