From: Sean Christopherson <sean.j.christopherson@intel.com> To: "Xing, Cedric" <cedric.xing@intel.com> Cc: linux-sgx@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, casey.schaufler@intel.com, jmorris@namei.org, luto@kernel.org, jethro@fortanix.com, greg@enjellic.com, sds@tycho.nsa.gov, jarkko.sakkinen@linux.intel.com Subject: Re: [RFC PATCH v3 0/4] security/x86/sgx: SGX specific LSM hooks Date: Mon, 8 Jul 2019 11:49:55 -0700 Message-ID: <20190708184955.GC20791@linux.intel.com> (raw) In-Reply-To: <8ba6c32d-cedc-53fd-9e86-f78be0067ac3@intel.com> On Mon, Jul 08, 2019 at 10:49:59AM -0700, Xing, Cedric wrote: > On 7/8/2019 8:55 AM, Sean Christopherson wrote: > >On Sun, Jul 07, 2019 at 04:41:30PM -0700, Cedric Xing wrote: > True only for SGX1. > >> “maximal protection” at page load time, but such information is NOT always > >> available. For example, Graphene containers may run different applications > >> comprised of different set of executables and/or shared objects. Some of > >> them may contain self-modifying code (or text relocation) while others > >> don’t. The generic enclave loader usually doesn’t have such information so > >> wouldn’t be able to provide it ahead of time. > > > >I'm unconvinced that it would be remotely difficult to teach an enclave > >loader that an enclave or hosted application employs SMC, relocation or > >any other behavior that would require declaring RWX on all pages. > > You've been talking as if "enclave loader" is tailored to the enclave it is > loading. But in reality "enclave loader" is usually a library knowing > usually nothing about the enclave. How could it know if an enclave contains > self-modifying code? Given the rarity of SMC, require enclaves to declare "I do SMC"... The Intel SDK already requires the enclave developer to declare heap size, stack size, thread affinity, etc... I have a very hard time believing that it can't support SMC and relocation flags. > >> · Inefficient Auditing – Audit logs are supposed to help system > >> administrators to determine the set of minimally needed permissions and to > >> detect abnormal behaviors. But consider the “maximal protection” model, if > >> “maximal protection” is set to be too permissive, then audit log wouldn’t > >> be able to detect anomalies; > > > >Huh? Declaring overly permissive protections is only problematic if an > >LSM denies the permission, in which case it will generate an accurate > >audit log. > > > >If the enclave/loader "requires" a permission it doesn't actually need, > >e.g. EXECDIRTY, then it's a software bug that should be fixed. I don't > >see how this scenario is any different than an application that uses > >assembly code without 'noexecstack' and inadvertantly "requires" > >EXECSTACK due to triggering "read implies exec". In both cases the > >denied permission is unnecessary due to a userspace application bug. > > You see, you've been assuming "enclave loader" knows everything and tailored > to what it loads in a particular application. But the reality is the loader > is generic and probably shared by multiple applications. No, I'm assuming that an enclave can communicate its basic needs without undue pain. > It needs some generic way to figure out the "maximal protection". An > implementation could use information embedded in the enclave file, or could > just be "configurable". In the former case, you put extra burdens on the build > tools, while in the latter case, your audit logs cannot help generating an > appropriate configuration. I'm contending the "extra burdens" is minimal. if (do_smc || do_relocation) max_prot = RWX; else max_prot = SECINFO.FLAGS; > >> or if “maximal protection” is too restrictive, > >> then audit log cannot identify the file violating the policy. > > > >Maximal protections that are too restrictive are completely orthogonal to > >LSMs as the enclave would fail to run irrespective of LSMs. This is no > >different than specifying the wrong RWX flags in SECINFO, or opening a > >file as RO instead of RW. > > Say loader is configurable. By looking at the log, can an administrator tell > which file has too restrictive "maximal protection"? Again, this fails irrespective of LSMs. So the answer is "no", because there is no log. But the admin will never have to deal with this issue because the enclave will *never* run, i.e. would unconditionally fail to run during initial development. And the developer has bigger problems if they can't debug their own code. > >>In either case the audit log cannot fulfill its purposes.
next prev parent reply index Thread overview: 156+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-19 22:23 [RFC PATCH v4 00/12] security: x86/sgx: SGX vs. LSM Sean Christopherson 2019-06-19 22:23 ` [RFC PATCH v4 01/12] x86/sgx: Use mmu_notifier.release() instead of per-vma refcounting Sean Christopherson 2019-06-20 21:03 ` Jarkko Sakkinen 2019-07-08 14:57 ` Sean Christopherson 2019-07-09 16:18 ` Jarkko Sakkinen 2019-06-19 22:23 ` [RFC PATCH v4 02/12] x86/sgx: Do not naturally align MAP_FIXED address Sean Christopherson 2019-06-20 21:09 ` Jarkko Sakkinen 2019-06-20 22:09 ` Jarkko Sakkinen 2019-06-19 22:23 ` [RFC PATCH v4 03/12] selftests: x86/sgx: Mark the enclave loader as not needing an exec stack Sean Christopherson 2019-06-20 21:17 ` Jarkko Sakkinen 2019-06-19 22:23 ` [RFC PATCH v4 04/12] x86/sgx: Require userspace to define enclave pages' protection bits Sean Christopherson 2019-06-21 1:07 ` Jarkko Sakkinen 2019-06-21 1:16 ` Jarkko Sakkinen 2019-06-21 16:42 ` Xing, Cedric 2019-07-08 16:34 ` Sean Christopherson 2019-07-08 17:29 ` Xing, Cedric 2019-07-01 18:00 ` Andy Lutomirski 2019-07-01 19:22 ` Xing, Cedric 2019-06-19 22:23 ` [RFC PATCH v4 05/12] x86/sgx: Enforce noexec filesystem restriction for enclaves Sean Christopherson 2019-06-21 1:26 ` Jarkko Sakkinen 2019-07-07 19:03 ` Sean Christopherson 2019-06-19 22:23 ` [RFC PATCH v4 06/12] mm: Introduce vm_ops->may_mprotect() Sean Christopherson 2019-06-21 1:35 ` Jarkko Sakkinen 2019-06-19 22:23 ` [RFC PATCH v4 07/12] LSM: x86/sgx: Introduce ->enclave_map() hook for Intel SGX Sean Christopherson 2019-06-21 2:28 ` Jarkko Sakkinen 2019-06-21 16:54 ` Xing, Cedric 2019-06-25 20:48 ` Stephen Smalley 2019-06-27 20:29 ` Xing, Cedric 2019-07-07 18:01 ` Sean Christopherson 2019-06-19 22:23 ` [RFC PATCH v4 08/12] security/selinux: Require SGX_MAPWX to map enclave page WX Sean Christopherson 2019-06-21 17:09 ` Xing, Cedric 2019-06-25 21:05 ` Stephen Smalley 2019-06-27 20:26 ` Xing, Cedric 2019-06-25 20:19 ` Stephen Smalley 2019-06-26 12:49 ` Dr. Greg 2019-06-19 22:23 ` [RFC PATCH v4 09/12] LSM: x86/sgx: Introduce ->enclave_load() hook for Intel SGX Sean Christopherson 2019-06-21 17:05 ` Xing, Cedric 2019-06-25 21:01 ` Stephen Smalley 2019-06-25 21:49 ` Stephen Smalley 2019-06-27 19:38 ` Xing, Cedric 2019-06-19 22:23 ` [RFC PATCH v4 10/12] security/selinux: Add enclave_load() implementation Sean Christopherson 2019-06-21 21:22 ` Xing, Cedric 2019-06-25 21:09 ` Stephen Smalley 2019-06-27 20:19 ` Xing, Cedric 2019-06-28 16:16 ` Stephen Smalley 2019-06-28 21:20 ` Xing, Cedric 2019-06-29 1:15 ` Stephen Smalley 2019-07-01 18:14 ` Xing, Cedric 2019-06-29 23:41 ` Andy Lutomirski 2019-07-01 17:46 ` Xing, Cedric 2019-07-01 17:53 ` Andy Lutomirski 2019-07-01 18:54 ` Xing, Cedric 2019-07-01 19:03 ` Xing, Cedric 2019-07-01 19:32 ` Andy Lutomirski 2019-07-01 20:03 ` Xing, Cedric 2019-07-07 18:46 ` Sean Christopherson 2019-06-25 20:34 ` Stephen Smalley 2019-06-19 22:24 ` [RFC PATCH v4 11/12] security/apparmor: " Sean Christopherson 2019-06-19 22:24 ` [RFC PATCH v4 12/12] LSM: x86/sgx: Show line of sight to LSM support SGX2's EAUG Sean Christopherson 2019-06-21 17:18 ` Xing, Cedric 2019-07-08 14:34 ` Sean Christopherson 2019-06-21 1:32 ` [RFC PATCH v4 00/12] security: x86/sgx: SGX vs. LSM Jarkko Sakkinen 2019-06-27 18:56 ` [RFC PATCH v2 0/3] security/x86/sgx: SGX specific LSM hooks Cedric Xing 2019-07-03 23:16 ` Jarkko Sakkinen 2019-07-03 23:22 ` Jarkko Sakkinen 2019-07-03 23:23 ` Jarkko Sakkinen 2019-07-06 5:04 ` Xing, Cedric 2019-07-08 14:46 ` Jarkko Sakkinen 2019-07-07 23:41 ` [RFC PATCH v3 0/4] " Cedric Xing 2019-07-08 15:55 ` Sean Christopherson 2019-07-08 17:49 ` Xing, Cedric 2019-07-08 18:49 ` Sean Christopherson [this message] 2019-07-08 22:26 ` Xing, Cedric 2019-07-07 23:41 ` [RFC PATCH v3 1/4] x86/sgx: Add " Cedric Xing 2019-07-07 23:41 ` [RFC PATCH v3 2/4] x86/64: Call LSM hooks from SGX subsystem/module Cedric Xing 2019-07-09 1:03 ` Sean Christopherson 2019-07-07 23:41 ` [RFC PATCH v3 3/4] X86/sgx: Introduce EMA as a new LSM module Cedric Xing 2019-07-08 16:26 ` Casey Schaufler 2019-07-08 17:16 ` Xing, Cedric 2019-07-08 23:53 ` Casey Schaufler 2019-07-09 22:13 ` Xing, Cedric 2019-07-10 0:10 ` Casey Schaufler 2019-07-10 0:55 ` Xing, Cedric 2019-07-10 21:14 ` Casey Schaufler 2019-07-11 13:51 ` Stephen Smalley 2019-07-11 15:12 ` Sean Christopherson 2019-07-11 16:11 ` Stephen Smalley 2019-07-11 16:25 ` Sean Christopherson 2019-07-11 16:32 ` Stephen Smalley 2019-07-11 23:41 ` Xing, Cedric 2019-07-07 23:41 ` [RFC PATCH v3 4/4] x86/sgx: Implement SGX specific hooks in SELinux Cedric Xing 2019-07-09 1:33 ` Sean Christopherson 2019-07-09 21:26 ` Xing, Cedric 2019-07-10 15:49 ` Sean Christopherson 2019-07-10 16:08 ` Jethro Beekman 2019-07-10 18:16 ` Xing, Cedric 2019-07-10 17:54 ` Xing, Cedric 2019-06-27 18:56 ` [RFC PATCH v2 1/3] x86/sgx: Add SGX specific LSM hooks Cedric Xing 2019-06-27 22:06 ` Casey Schaufler 2019-06-27 22:52 ` Xing, Cedric 2019-06-27 23:37 ` Casey Schaufler 2019-06-28 0:47 ` Xing, Cedric 2019-06-28 17:22 ` Casey Schaufler 2019-06-28 22:29 ` Xing, Cedric 2019-06-29 1:37 ` Stephen Smalley 2019-06-29 21:35 ` Casey Schaufler 2019-07-01 17:57 ` Xing, Cedric 2019-07-01 19:53 ` Casey Schaufler 2019-07-01 21:45 ` Xing, Cedric 2019-07-01 23:11 ` Casey Schaufler 2019-07-02 7:42 ` Xing, Cedric 2019-07-02 15:44 ` Casey Schaufler 2019-07-03 9:46 ` Dr. Greg 2019-07-03 15:32 ` Casey Schaufler 2019-07-07 13:30 ` Dr. Greg 2019-07-09 0:02 ` Casey Schaufler 2019-07-09 1:52 ` Sean Christopherson 2019-07-09 21:16 ` Xing, Cedric 2019-07-11 10:22 ` Dr. Greg 2019-07-15 22:23 ` Andy Lutomirski 2019-06-28 16:37 ` Stephen Smalley 2019-06-28 21:53 ` Xing, Cedric 2019-06-29 1:22 ` Stephen Smalley 2019-07-01 18:02 ` Xing, Cedric 2019-06-29 23:46 ` Andy Lutomirski 2019-07-01 17:11 ` Xing, Cedric 2019-07-01 17:58 ` Andy Lutomirski 2019-07-01 18:31 ` Xing, Cedric 2019-07-01 19:36 ` Andy Lutomirski 2019-07-01 19:56 ` Xing, Cedric 2019-07-02 2:29 ` Andy Lutomirski 2019-07-02 6:35 ` Xing, Cedric 2019-06-27 18:56 ` [RFC PATCH v2 2/3] x86/sgx: Call LSM hooks from SGX subsystem/module Cedric Xing 2019-06-27 18:56 ` [RFC PATCH v2 3/3] x86/sgx: Implement SGX specific hooks in SELinux Cedric Xing 2019-07-05 16:05 ` [RFC PATCH v4 00/12] security: x86/sgx: SGX vs. LSM Jarkko Sakkinen 2019-07-08 17:29 ` Sean Christopherson 2019-07-08 17:33 ` Xing, Cedric 2019-07-09 16:22 ` Jarkko Sakkinen 2019-07-09 17:09 ` Sean Christopherson 2019-07-09 20:41 ` Xing, Cedric 2019-07-09 22:25 ` Sean Christopherson 2019-07-09 23:11 ` Xing, Cedric 2019-07-10 16:57 ` Sean Christopherson 2019-07-10 20:19 ` Jarkko Sakkinen 2019-07-10 20:31 ` Sean Christopherson 2019-07-11 9:06 ` Jarkko Sakkinen 2019-07-10 22:00 ` Jarkko Sakkinen 2019-07-10 22:16 ` Jarkko Sakkinen 2019-07-10 23:16 ` Xing, Cedric 2019-07-11 9:26 ` Jarkko Sakkinen 2019-07-11 14:32 ` Stephen Smalley 2019-07-11 17:51 ` Jarkko Sakkinen 2019-07-12 0:08 ` Xing, Cedric 2019-07-10 1:28 ` Dr. Greg 2019-07-10 2:04 ` Xing, Cedric 2019-07-10 3:21 ` Jethro Beekman
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=20190708184955.GC20791@linux.intel.com \ --to=sean.j.christopherson@intel.com \ --cc=casey.schaufler@intel.com \ --cc=cedric.xing@intel.com \ --cc=greg@enjellic.com \ --cc=jarkko.sakkinen@linux.intel.com \ --cc=jethro@fortanix.com \ --cc=jmorris@namei.org \ --cc=linux-security-module@vger.kernel.org \ --cc=linux-sgx@vger.kernel.org \ --cc=luto@kernel.org \ --cc=sds@tycho.nsa.gov \ --cc=selinux@vger.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
Linux-Sgx Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-sgx/0 linux-sgx/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-sgx linux-sgx/ https://lore.kernel.org/linux-sgx \ linux-sgx@vger.kernel.org public-inbox-index linux-sgx Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-sgx AGPL code for this site: git clone https://public-inbox.org/public-inbox.git