[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4405992a-8fad-f95a-b01b-f7a9412dd57f@schaufler-ca.com>
Date: Thu, 27 Jan 2022 18:33:18 -0800
From: Casey Schaufler <casey@...aufler-ca.com>
To: Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>
Cc: Christian Brauner <christian.brauner@...ntu.com>,
Christian Brauner <christian@...uner.io>,
Linux Security Module list
<linux-security-module@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
syzbot <syzbot+d1e3b1d92d25abf97943@...kaller.appspotmail.com>,
David Howells <dhowells@...hat.com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
selinux@...r.kernel.org, Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: [PATCH v2] LSM: general protection fault in legacy_parse_param
On 1/27/2022 5:44 PM, Paul Moore wrote:
> On Thu, Jan 27, 2022 at 12:46 PM James Morris <jmorris@...ei.org> wrote:
>> On Thu, 27 Jan 2022, Casey Schaufler wrote:
>>
>>> The usual LSM hook "bail on fail" scheme doesn't work for cases where
>>> a security module may return an error code indicating that it does not
>>> recognize an input. In this particular case Smack sees a mount option
>>> that it recognizes, and returns 0. A call to a BPF hook follows, which
>>> returns -ENOPARAM, which confuses the caller because Smack has processed
>>> its data.
>>>
>>> The SELinux hook incorrectly returns 1 on success. There was a time
>>> when this was correct, however the current expectation is that it
>>> return 0 on success. This is repaired.
>>>
>>> Reported-by: syzbot+d1e3b1d92d25abf97943@...kaller.appspotmail.com
>>> Signed-off-by: Casey Schaufler <casey@...aufler-ca.com>
>>
>> Acked-by: James Morris <jamorris@...ux.microsoft.com>
> Looks good to me too, thanks Casey. Since James' already ACK'd it, I
> went ahead and pulled this into selinux/next.
Works for me. It was either James' tree or the SELinux tree.
Going through the security tree may have made more sense because
the original problem was reported against Smack, but that tree
isn't very active.
>
>>> ---
>>> security/security.c | 17 +++++++++++++++--
>>> security/selinux/hooks.c | 5 ++---
>>> 2 files changed, 17 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/security/security.c b/security/security.c
>>> index 3d4eb474f35b..e649c8691be2 100644
>>> --- a/security/security.c
>>> +++ b/security/security.c
>>> @@ -884,9 +884,22 @@ int security_fs_context_dup(struct fs_context *fc, struct
>>> fs_context *src_fc)
>>> return call_int_hook(fs_context_dup, 0, fc, src_fc);
>>> }
>>>
>>> -int security_fs_context_parse_param(struct fs_context *fc, struct
>>> fs_parameter *param)
>>> +int security_fs_context_parse_param(struct fs_context *fc,
>>> + struct fs_parameter *param)
>>> {
>>> - return call_int_hook(fs_context_parse_param, -ENOPARAM, fc, param);
>>> + struct security_hook_list *hp;
>>> + int trc;
>>> + int rc = -ENOPARAM;
>>> +
>>> + hlist_for_each_entry(hp, &security_hook_heads.fs_context_parse_param,
>>> + list) {
>>> + trc = hp->hook.fs_context_parse_param(fc, param);
>>> + if (trc == 0)
>>> + rc = 0;
>>> + else if (trc != -ENOPARAM)
>>> + return trc;
>>> + }
>>> + return rc;
>>> }
>>>
>>> int security_sb_alloc(struct super_block *sb)
>>> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>>> index 5b6895e4fc29..371f67a37f9a 100644
>>> --- a/security/selinux/hooks.c
>>> +++ b/security/selinux/hooks.c
>>> @@ -2860,10 +2860,9 @@ static int selinux_fs_context_parse_param(struct
>>> fs_context *fc,
>>> return opt;
>>>
>>> rc = selinux_add_opt(opt, param->string, &fc->security);
>>> - if (!rc) {
>>> + if (!rc)
>>> param->string = NULL;
>>> - rc = 1;
>>> - }
>>> +
>>> return rc;
>>> }
Powered by blists - more mailing lists