Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp2042290yba; Fri, 17 May 2019 09:26:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqwZQ3W2Be5/wGAy/qfu5NVUm5M2yjAykE6fQ2yRkrWacS6ScldIUvKpZ84MXYT2skBu6QQ4 X-Received: by 2002:a63:2d0:: with SMTP id 199mr662602pgc.188.1558110373420; Fri, 17 May 2019 09:26:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558110373; cv=none; d=google.com; s=arc-20160816; b=pkx9fzmruzQAj03kAgJmlQKZmQF2NkmnTH8MpaiM36ekJOOdqASq3ybX5hR6pX1Ttz Ic43uzNiHC4vd/UWqijUWDFT//Jc7CSG49F/oYfVlZkN+LR4qoq88fqXztYdqr3MnDUP 2QO5IO09qiATTvE4uT9XQ8eps1j0Ul2qyn0YKWQtUi1mos3tkEuVeZT/doAIGPBL2g7m rH2ITwE4ceE2o+hleZfXPJtmUaNMRuUj2UBqbe+Q+6Yp6fFzX5X88eAtUj5E1ZSxoPYi SuIsr55NT8Lh/N+J4F0BWSJzsVcUyq//WzxAafdJDYZ+N76vbBA8BrMYOLAl0NaZBXl/ 6EbA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=aV3rffMxuXG8e12nRoLl587y9MXM8TOV+Ti1qX5jxqI=; b=tD5jIy/cdC57l29bbYqhL9I0R/tkuRTnZdIlDR3RZ51Wk6CmHskoaaC091xLTZc/oB eglpfJG6F2/MIJCy6/HbwdNBWmjdI1Qw4rwmZGY6MNkKOxG61vb6QpASvYje9nsqApy9 bLs14FKZOrRFVkecjUZWHnYNm8c/feXM3dxqOWmv6TBUV5FL28pJogRAd7euMI1Wf6ki TbsUIn2y9jlM0iht0nLf6viWf/m1Mai0OeXiFZPWz7MDFEP1A3T/MOwNTsBecfC25GEy M90UPSJFTlPm4tsJk3TGfw3+xFMSM7/STpeG7d4s0nAH+jLSTDcAzfiInDVwTzKY+0Wq 5CTg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=NXpueBp2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d18si8169168pgo.525.2019.05.17.09.25.57; Fri, 17 May 2019 09:26:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=NXpueBp2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725985AbfEQQYn (ORCPT + 99 others); Fri, 17 May 2019 12:24:43 -0400 Received: from mail-pl1-f194.google.com ([209.85.214.194]:46019 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725933AbfEQQYn (ORCPT ); Fri, 17 May 2019 12:24:43 -0400 Received: by mail-pl1-f194.google.com with SMTP id a5so3552299pls.12 for ; Fri, 17 May 2019 09:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aV3rffMxuXG8e12nRoLl587y9MXM8TOV+Ti1qX5jxqI=; b=NXpueBp2RQMTp7/ult69Cy5m/zTxwcPQ4jUpkeJZIDfT5NUWtRfdwnURyUvF+j6BFp AtAoNq/qumpwpOFcKFiEZaF/sZdU1y/HLKnK9X7UPX0N/K43J1jkVrMf5Xs5CqVetGcL ZBfYzEeuzoVND9qwgMHdjgycO60Wj5qtT1MAM5cT1Ytwi56EKX3k7ReMiyMZ8xdGHNre mM4fVZcEHDooxUjnhbVinIyKSNOV8KWA1dtbI6Y7eb62sxO2ITHJnViW49OB1VjvhKtv DGINjLmb++niWPUIc88gcCTcevakt4/DwbPMhlaoWreegbl0aeJ3i93b5EK1cmpI033W Wulg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aV3rffMxuXG8e12nRoLl587y9MXM8TOV+Ti1qX5jxqI=; b=EJFKlFa7R/jf3zRWgfTmhZmwtHYEAY+q4Yzxp62Mr30jqFBJKSYDFAxlHQe7bGxKY6 R1/PpX9FiPcKZ2Wji8WuBdYkVhWLOo+EukYixAFk/AvNJ8tWnGfIIbejeOH25615/S+U YXA1nQ1TyrElsbTFQuOwCdQFViJW3x2OHQrjCSDV4sriSiA6ib1ylf/VzCG47t7ZA14A U461D1y6xGEcOWylcrYUuoeZB29OjGso0IWBVGoSXvTro/q374+AvuE1s6Xllnl3qMJV 9QDIhuLl2QJ2EPCYCPBCF+zwaGNgu4tEzpE+bIWPk6iA1cDa7fKejFKzWydHaCdW0lc0 rhrw== X-Gm-Message-State: APjAAAXis+jPu0ujI45rwJNzqHIp2Ap7bH5STbyUWZMHegxGgNf4tfFE dImcikQ8GEc1LaI+NPKYAqfc8Q== X-Received: by 2002:a17:902:be0e:: with SMTP id r14mr40513480pls.152.1558110282349; Fri, 17 May 2019 09:24:42 -0700 (PDT) Received: from ?IPv6:2600:1010:b066:f2e9:80d1:f40f:2e81:3df1? ([2600:1010:b066:f2e9:80d1:f40f:2e81:3df1]) by smtp.gmail.com with ESMTPSA id k9sm10974460pfa.180.2019.05.17.09.24.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 May 2019 09:24:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support) From: Andy Lutomirski X-Mailer: iPhone Mail (16E227) In-Reply-To: Date: Fri, 17 May 2019 09:24:39 -0700 Cc: Sean Christopherson , "Xing, Cedric" , Andy Lutomirski , James Morris , "Serge E. Hallyn" , LSM List , Paul Moore , Eric Paris , "selinux@vger.kernel.org" , Jarkko Sakkinen , Jethro Beekman , "Hansen, Dave" , Thomas Gleixner , "Dr. Greg" , Linus Torvalds , LKML , X86 ML , "linux-sgx@vger.kernel.org" , Andrew Morton , "nhorman@redhat.com" , "npmccallum@redhat.com" , "Ayoun, Serge" , "Katz-zamir, Shay" , "Huang, Haitao" , Andy Shevchenko , "Svahn, Kai" , Borislav Petkov , Josh Triplett , "Huang, Kai" , David Rientjes Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190515013031.GF1977@linux.intel.com> <960B34DE67B9E140824F1DCDEC400C0F654E38CD@ORSMSX116.amr.corp.intel.com> <960B34DE67B9E140824F1DCDEC400C0F654E3FB9@ORSMSX116.amr.corp.intel.com> <6a97c099-2f42-672e-a258-95bc09152363@tycho.nsa.gov> <20190517150948.GA15632@linux.intel.com> To: Stephen Smalley Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On May 17, 2019, at 9:20 AM, Stephen Smalley wrote: >=20 >> On 5/17/19 11:09 AM, Sean Christopherson wrote: >>> On Fri, May 17, 2019 at 09:53:06AM -0400, Stephen Smalley wrote: >>>> On 5/16/19 6:23 PM, Xing, Cedric wrote: >>>> I thought EXECMOD applied to files (and memory mappings backed by them)= but >>>> I was probably wrong. It sounds like EXECMOD applies to the whole proce= ss so >>>> would allow all pages within a process's address space to be modified t= hen >>>> executed, regardless the backing files. Am I correct this time? >>>=20 >>> No, you were correct the first time I think; EXECMOD is used to control >>> whether a process can make executable a private file mapping that has >>> previously been modified (e.g. text relocation); it is a special case to= >>> support text relocations without having to allow full EXECMEM (i.e. exec= ute >>> arbitrary memory). >>>=20 >>> SELinux checks relevant to W^X include: >>>=20 >>> - EXECMEM: mmap/mprotect PROT_EXEC an anonymous mapping (regardless of >>> PROT_WRITE, since we know the content has to have been written at some >>> point) or a private file mapping that is also PROT_WRITE. >>> - EXECMOD: mprotect PROT_EXEC a private file mapping that has been >>> previously modified, typically for text relocations, >>> - FILE__WRITE: mmap/mprotect PROT_WRITE a shared file mapping, >>> - FILE__EXECUTE: mmap/mprotect PROT_EXEC a file mapping. >>>=20 >>> (ignoring EXECSTACK and EXECHEAP here since they aren't really relevant t= o >>> this discussion) >>>=20 >>> So if you want to ensure W^X, then you wouldn't allow EXECMEM for the >>> process, EXECMOD by the process to any file, and the combination of both= >>> FILE__WRITE and FILE__EXECUTE by the process to any file. >>>=20 >>> If the /dev/sgx/enclave mappings are MAP_SHARED and you aren't using an >>> anonymous inode, then I would expect that only the FILE__WRITE and >>> FILE__EXECUTE checks are relevant. >> Yep, I was just typing this up in a different thread: >> I think we may want to change the SGX API to alloc an anon inode for each= >> enclave instead of hanging every enclave off of the /dev/sgx/enclave inod= e. >> Because /dev/sgx/enclave is NOT private, SELinux's file_map_prot_check() >> will only require FILE__WRITE and FILE__EXECUTE to mprotect() enclave VMA= s >> to RWX. Backing each enclave with an anon inode will make SELinux treat >> EPC memory like anonymous mappings, which is what we want (I think), e.g.= >> making *any* EPC page executable will require PROCESS__EXECMEM (SGX is >> 64-bit only at this point, so SELinux will always have default_noexec). >=20 > I don't think we want to require EXECMEM (or equivalently both FILE__WRITE= and FILE__EXECUTE to /dev/sgx/enclave) for making any EPC page executable, o= nly if the page is also writable or previously modified. The intent is to p= revent arbitrary code execution without EXECMEM (or FILE__WRITE|FILE__EXECUT= E), while still allowing enclaves to be created without EXECMEM as long as t= he EPC page mapping is only ever mapped RX and its initial contents came fro= m an unmodified file mapping that was PROT_EXEC (and hence already checked v= ia FILE__EXECUTE). That agrees with my thoughts. Actually plumbing everything together so this w= orks could be a bit interesting. I assume it=E2=80=99ll need a special case= in SELinux or maybe a new vm_op.=