linux-kernel - Re: [PATCH] general protection fault in sock_has

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 19 Jan 2018 09:34:36 -0800
From:   Mark Salyzyn <salyzyn@...roid.com>
To:     Stephen Smalley <sds@...ho.nsa.gov>, linux-kernel@...r.kernel.org
Cc:     Paul Moore <paul@...l-moore.com>,
        Eric Paris <eparis@...isplace.org>,
        James Morris <james.l.morris@...cle.com>,
        "Serge E. Hallyn" <serge@...lyn.com>, selinux@...ho.nsa.gov,
        linux-security-module@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH] general protection fault in sock_has_perm

On 01/19/2018 09:19 AM, Stephen Smalley wrote:
> On Thu, 2018-01-18 at 13:58 -0800, Mark Salyzyn wrote:
>> general protection fault: 0000 [#1] PREEMPT SMP KASAN
>> . . .
>>
>> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>> index 8644d864e3c1..95d7c8143373 100644
>> --- a/security/selinux/hooks.c
>> +++ b/security/selinux/hooks.c
>> @@ -4342,7 +4342,7 @@ static int sock_has_perm(struct sock *sk, u32
>> perms)
>>   	struct common_audit_data ad;
>>   	struct lsm_network_audit net = {0,};
>>   
>> -	if (sksec->sid == SECINITSID_KERNEL)
>> +	if (!sksec || sksec->sid == SECINITSID_KERNEL)
>>   		return 0;
> The patch description says "null check the sk_security, and if the
> case, reject the permissions."  The patch code instead has it return
> 0/success, i.e. permission granted.  Which one is correct?
<oops> -EACCESS would be advised, yes. THANKS.

<please remove my mistake from my permanent record ;-} >
> If we
> return -EACCES, then we might break userspace; if we return 0, we might
> be allowing an operation that should have been denied.  Both seem like
> losing propositions.
if the sk_security is NULL, it is in-effect a form of UAF, so kernel 
_and_ user space is already 'sick'. I think it is a significantly larger 
losing proposition to panic the kernel? Reporting -EACCESS (as was 
proper) is a error propagation way to let user space deal with the 
erroneous condition.

>
> Could we instead have selinux_sk_free_security() defer freeing of the
> sock security blob to a call_rcu(), like we did for
> inode_free_security, or change the caller of it to not free it until
> the sock is truly freed?

AFAIK the upper issue is the premature closing on an RCU protected 
object, and the _right_ answer is that its call should have been 
properly deferred to a synchronization or grace period. Having 
sk_free_security be deferred by the grace period runs the risk that it 
is in a race with the proper deletion of a languishing read object in an 
RCU. It is a bug in the upper layers. My proposal in this KISS stability 
patch is to make security deal with those bugs gracefully until all 
those issues are fixed (in ToT).

-- Mark