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
>>>
next prev parent 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