From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-122530-1516383475-2-808235970321016793 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no X-Spam-score: 0.0 X-Spam-hits: BAYES_00 -1.9, HEADER_FROM_DIFFERENT_DOMAINS 0.25, RCVD_IN_DNSWL_HI -5, T_RP_MATCHES_RCVD -0.01, LANGUAGES en, BAYES_USED global, SA_VERSION 3.4.0 X-Spam-source: IP='209.132.180.67', Host='vger.kernel.org', Country='US', FromHeader='com', MailFrom='org' X-Spam-charsets: plain='utf-8' X-Resolved-to: greg@kroah.com X-Delivered-to: greg@kroah.com X-Mail-from: stable-owner@vger.kernel.org ARC-Seal: i=1; a=rsa-sha256; cv=none; d=messagingengine.com; s=arctest; t=1516383474; b=miSR3jSu6ve3pt/GZCEPAwIIOdB3mZDpJlEFf3mTo68Dc4v DNMkMKj4BvXHLgi/6kcVSQRS5ztDeTjzilCzqGwS2CC1MSxULN33Gt8L2Sf5rT8D 1Zq1mnecDWJV8TsP9AImAYuKIUGOmgyxqfSAikfMRgqVViJoZb6UlG0LeZOH9s2I 3fQnZy3ASY7P82hy3sPCMTWuJxMkPX7l53ajPKZBgbY7wW35ArdEUjQfJQOdUbbU V5YUU6sLOE0t9blg+k//4JdFTEi8LQYpQ3Gh1Lq6B2phBFPbpfc54alutezE7/jX zib+kSNmhuKBhqq3ieMQmFDi4NewXB0dBFogy9Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=subject:to:cc:references:from:message-id :date:mime-version:in-reply-to:content-type :content-transfer-encoding:sender:list-id; s=arctest; t= 1516383474; bh=tlIRi8lpc3ZzLoLSrmgVqNBThpUP2e3q6gojdsJY7bM=; b=Z jOox43wDqwN/8QRmXiCuc8d7dCt+UvZ+79Yr+fRKyqWxjAdPY7wxL1FLmUb9idWG oQTrCsRY37Bq050e6FaxNcwFeMs63+XletK3OLTnnte5ow0idhhMbfSUcRhwbM15 zGbD9jTLiFi+zOFye6A+UNFwI2kZUWUGqouhl5V7PE8hRE/VwtdXTA1Y/FCCxNip 2prb7d6ZmNK2LifFOi5VrThJsuHu9TMwKz3inetq8a8f9oqGvsNe2neJZRsmIQa6 oYo2EDiejfzNnx/vw2qD3up/3DcEGEmRdnDZjPWLRKLM1ByCoP5lMI9WV9GL7hE5 1xl3760fYotHsHyvadV0A== ARC-Authentication-Results: i=1; mx1.messagingengine.com; arc=none (no signatures found); dkim=pass (2048-bit rsa key sha256) header.d=yahoo.com header.i=@yahoo.com header.b=ixilhane x-bits=2048 x-keytype=rsa x-algorithm=sha256 x-selector=s2048; dmarc=none (p=none,has-list-id=yes,d=none) header.from=schaufler-ca.com; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=stable-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=schaufler-ca.com header.result=pass header_is_org_domain=yes Authentication-Results: mx1.messagingengine.com; arc=none (no signatures found); dkim=pass (2048-bit rsa key sha256) header.d=yahoo.com header.i=@yahoo.com header.b=ixilhane x-bits=2048 x-keytype=rsa x-algorithm=sha256 x-selector=s2048; dmarc=none (p=none,has-list-id=yes,d=none) header.from=schaufler-ca.com; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=stable-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=schaufler-ca.com header.result=pass header_is_org_domain=yes Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755981AbeASRhv (ORCPT ); Fri, 19 Jan 2018 12:37:51 -0500 Received: from sonic312-28.consmr.mail.ne1.yahoo.com ([66.163.191.209]:40631 "EHLO sonic312-28.consmr.mail.ne1.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755899AbeASRhu (ORCPT ); Fri, 19 Jan 2018 12:37:50 -0500 X-YMail-OSG: HSXnCTcVM1n7_lprUDEDuIWqkqRxfyK0FF_x2Hn8FHWYK7UXF.GffsDA1E.iaRK 7QHFEyjv9hr7pKTcdgoMW2DK8Gl9.AJcRKjIfSIGXdZKvYad5blTFeLW3Bfki9m5oJrOmYvtWtPa VpAJsWv8BPoVIJB9vHi2hzNBquo83X75wGNmkDrpwzpQIornmEXSlsKI38SeD0OqO.XAKnila63g sKQ4Xs41eeLsD2cVMiwQsDDFkrEnvx69sscn_RSg4U7uPmM0taNcXxDrEI4.n8M3ps7NHynEP2gb IutlHCAr8otTuK5M0nS7adZS7wzub.LV2UBtIPcOzsc6YdTxoGSjOPXrBluilUnJkY34q5.lCAWw 27e4DlOdQEfMRCIhg5svADmuNS20jsjbRP9m4mxgTkducxDzvzz87iLgC7Jx9j7EkQTYs1iinHJE gB5caEzgPTKEU2BcviYjNul3Ds7eCdXdzjsa5un9d.MjFDzi8f0r.ZN4S8u0mXAE_FMIC127R1Tz J2C4wN38TNHGzSRFarBGmY7P9ei4no.OoJEN4EnsU9cB2D7_3TNX3XpoutBHH Subject: Re: [PATCH] general protection fault in sock_has_perm To: Paul Moore , Mark Salyzyn Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov, Stephen Smalley References: <20180118215853.228182-1-salyzyn@android.com> <1f185712-9136-be88-02c0-5613a7683619@android.com> From: Casey Schaufler Message-ID: Date: Fri, 19 Jan 2018 09:37:43 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Sender: stable-owner@vger.kernel.org X-Mailing-List: stable@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 1/19/2018 9:06 AM, Paul Moore wrote: > On Fri, Jan 19, 2018 at 10:49 AM, Mark Salyzyn wrote: >> On 01/18/2018 02:36 PM, Paul Moore wrote: >>> On Thu, Jan 18, 2018 at 4:58 PM, Mark Salyzyn wrote: >>>> general protection fault: 0000 [#1] PREEMPT SMP KASAN >>>> CPU: 1 PID: 14233 Comm: syz-executor2 Not tainted 4.4.112-g5f6325b #28 >>>> . . . >>>> [] selinux_socket_setsockopt+0x4d/0x80 >>>> security/selinux/hooks.c:4338 >>>> [] security_socket_setsockopt+0x7d/0xb0 >>>> security/security.c:1257 >>>> [] SYSC_setsockopt net/socket.c:1757 [inline] >>>> [] SyS_setsockopt+0xe8/0x250 net/socket.c:1746 >>>> [] entry_SYSCALL_64_fastpath+0x16/0x92 >>>> Code: c2 42 9b b6 81 be 01 00 00 00 48 c7 c7 a0 cb 2b 84 e8 >>>> f7 2f 6d ff 49 8d 7d 10 48 b8 00 00 00 00 00 fc ff df 48 89 >>>> fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 83 01 00 >>>> 00 41 8b 75 10 31 >>>> RIP [] sock_has_perm+0x1fe/0x3e0 >>>> security/selinux/hooks.c:4069 >>>> RSP >>>> ---[ end trace 7b5aaf788fef6174 ]--- >>>> >>>> In the absence of commit a4298e4522d6 ("net: add SOCK_RCU_FREE socket >>>> flag") and all the associated infrastructure changes to take advantage >>>> of a RCU grace period before freeing, there is a heightened >>>> possibility that a security check is performed while an ill-timed >>>> setsockopt call races in from user space. It then is prudent to null >>>> check sk_security, and if the case, reject the permissions. >>>> >>>> This adjustment is orthogonal to infrastructure improvements that may >>>> nullify the needed check, but should be added as good code hygiene. >>> I'm skeptical that this is the full solution for systems that lack the >>> SOCK_RCU_FREE protection. Is this really limited to just >>> setsockopt()? >> Maybe overstepped in my analysis and assumptions? >> >> This is a result of a fuzzer hitting an android 4.4 KASAN kernel. We (so >> far) have _not_ seen this with an android 4.9 KASAN kernel (which has the >> SOCK_RCU_FREE adjustments). There is no standalone duplication or PoC >> _except_ via the fuzzer. The rest of the statements stands based on this >> tidbit (statements of general good code hygiene, not 100% sure SOCK_RCU_FREE >> usage is completely covered, KISS solution etc). >> >> To be honest, yes, this may be a layer in the onion (swat this NULL check >> does not by itself solve the _problem_), I'd prefer kernel continuing on in >> a rational manner rather than panic ... and I have a gut feeling this could >> be a gratuitous NULL check if all the bugs in the network layer have been >> solved . Programming to solve a problem >> with one's gut is not a good practice, but hygiene is. This is 10 >> characters, and an estimated 1.2ns of added hygiene. >> >> No, I do not think this is limited to setsockopt, but would be willing to >> believe a multithreaded attack of any socket functions or ioctl would drop >> down to the check with sock_has_perm at possibly the wrong time in socket >> teardown. > I'm not necessarily opposed to adding additional safety checks, if > warranted, but I am opposed to adding a single check and declaring > mission accomplished when there is a suspicion that additional checks > may be needed. > > Perhaps in this particular case it really is only setsockopt(), but > from what I can tell from your comments and the SOCK_RCU_FREE commit > message it would appear that there is a race condition here between a > socket's lifetime and its visibility to userspace. Assuming this is > the core problem you are trying to workaround with this patch, I > suspect that more than just the SELinux/LSM hook for setsockopt() is > affected; before merging this patch I would like to see a better > investigation into all the socket related SELinux/LSM hooks to see if > they suffer from the same problem. There have been a few cases where Smack has been affected in similar ways outside of setsockopt(). If there's a problem here there's likely to be a problem in Smack that presents itself in a very different way. > For example, if we stick with the setsockopt() syscall and the > SELinux/LSM hook we can see that there are two functions which access > the socket struct: sock_has_perm() and > selinux_netlbl_socket_setsockopt(). While you did add the safety > check to sock_has_perm() you neglected to add a check to > selinux_netlbl_socket_setsockopt(), I'm guessing because the Android > kernels probably do not enable CONFIG_NETLABEL. Looking beyond > setsockopt() into other socket related syscalls I see a number of > hooks which should have similar protections. > > When you see problems like this, please do the investigation to make > sure you are fixing everything like it and not just the one instance > that blew up. >