From: "Xing, Cedric" <cedric.xing@intel.com>
To: Stephen Smalley <sds@tycho.nsa.gov>,
"linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>,
"selinux@vger.kernel.org" <selinux@vger.kernel.org>
Cc: "Schaufler, Casey" <casey.schaufler@intel.com>,
"jmorris@namei.org" <jmorris@namei.org>,
"luto@kernel.org" <luto@kernel.org>,
"jethro@fortanix.com" <jethro@fortanix.com>,
"greg@enjellic.com" <greg@enjellic.com>,
"jarkko.sakkinen@linux.intel.com"
<jarkko.sakkinen@linux.intel.com>,
"Christopherson, Sean J" <sean.j.christopherson@intel.com>
Subject: RE: [RFC PATCH v2 1/3] x86/sgx: Add SGX specific LSM hooks
Date: Fri, 28 Jun 2019 21:53:46 +0000 [thread overview]
Message-ID: <960B34DE67B9E140824F1DCDEC400C0F6551C45F@ORSMSX116.amr.corp.intel.com> (raw)
In-Reply-To: <f36415e6-5a69-b1b9-74b6-87a9af4508d3@tycho.nsa.gov>
> From: linux-sgx-owner@vger.kernel.org [mailto:linux-sgx-
> owner@vger.kernel.org] On Behalf Of Stephen Smalley
> Sent: Friday, June 28, 2019 9:37 AM
>
> > lsm.ema.cache_decisions is on by default and
> > could be turned off by appending “lsm.ema.cache_decisions=0” or
> > “lsm.ema.cache_decisions=off” to the kernel command line.
>
> This seems problematic on a few fronts:
>
> - Specifying it as a boot parameter requires teaching admins / policy
> developers to do something in addition to what they are already doing
> when they want to create policy,
>
> - Limiting it to a boot parameter requires a reboot to change the mode
> of operation, whereas SELinux offers runtime toggling of permissive mode
> and even per-process (domain) permissive mode (and so does AppArmor),
How about making a variable tunable via sysctl?
>
> - In the cache_decisions=1 case, do we get any auditing at all? If not,
> that's a problem. We want auditing not only when we are
> generating/learning policy but also in operation.
Currently it doesn't generate audit log, but I could add it, except it couldn't point to the exact file. But I can use the sigstruct file instead so administrators can at least tell which enclave violates the policy. Do you think it acceptable?
>
> - There is the potential for inconsistencies to arise between the
> enforcement applied with different cache_decisions values.
The enforcement will be consistent. The difference only lies in the logs.
>
> I would suggest that we just never cache the decision and accept the
> cost if we are going to take this approach.
This will also be a viable option. I don't think any enclaves would be comprised of a large number of files anyway. When SGX2 comes up, I think most enclaves will be instantiated from only one file and defer loading libraries at runtime. So in practice we are looking to keeping only one file open per enclave, which seems totally acceptable.
Stephen (and everyone having an opinion on this), which way do you prefer? sysctl variable? Or never cache decisions?
next prev parent reply other threads:[~2019-06-28 21:53 UTC|newest]
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
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 [this message]
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=960B34DE67B9E140824F1DCDEC400C0F6551C45F@ORSMSX116.amr.corp.intel.com \
--to=cedric.xing@intel.com \
--cc=casey.schaufler@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=sean.j.christopherson@intel.com \
--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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).