[RFC PATCH v4 00/12] security: x86/sgx: SGX vs. LSM
sean.j.christopherson at intel.com
Tue Jul 9 17:09:17 UTC 2019
On Tue, Jul 09, 2019 at 07:22:03PM +0300, Jarkko Sakkinen wrote:
> On Mon, Jul 08, 2019 at 10:29:30AM -0700, Sean Christopherson wrote:
> > On Fri, Jul 05, 2019 at 07:05:49PM +0300, Jarkko Sakkinen wrote:
> > > On Wed, Jun 19, 2019 at 03:23:49PM -0700, Sean Christopherson wrote:
> > >
> > > I still don't get why we need this whole mess and do not simply admit
> > > that there are two distinct roles:
> > >
> > > 1. Creator
> > > 2. User
> > Because SELinux has existing concepts of EXECMEM and EXECMOD.
> What is the official documentation for those? I've only found some
> explanations from discussions and some RHEL sysadmin guides.
No clue. My knowledge was gleaned from the code and from Stephen's
The high level breakdown:
- FILE__EXECUTE: required to gain X on a mapping to a regular file
- FILE__EXECUTE + FILE__WRITE: required to gain WX or W->X on a shared
mapping to a regular file
- FILE__EXECMOD: required to gain W->X on a private mapping of a regular
- PROCESS__EXECMEM: required to gain WX on a private mapping to a regular
file, OR to gain X on an anonymous mapping.
Translating those to SGX, with a lot of input from Stephen, I ended up
with the following:
- FILE__ENCLAVE_EXECUTE: equivalent to FILE__EXECUTE, required to gain X
on an enclave page loaded from a regular file
- PROCESS2__ENCLAVE_EXECDIRTY: hybrid of EXECMOD and EXECUTE+WRITE,
required to gain W->X on an enclave page
- PROCESS2__ENCLAVE_EXECANON: subset of EXECMEM, required to gain X on
an enclave page that is loaded from an
- PROCESS2__ENCLAVE_MAPWX: subset of EXECMEM, required to gain WX on an
> > That being said, we can do so without functional changes to the SGX uapi,
> > e.g. add reserved fields so that the initial uapi can be extended *if* we
> > decide to go with the "userspace provides maximal protections" path, and
> > use the EPCM permissions as the maximal protections for the initial
> > upstreaming.
> > That'd give us a minimal implemenation for initial upstreaming and would
> > eliminate Cedric's blocking complaint. The "whole mess" of whitelisting,
> > blacklisting and SGX2 support would be deferred until post-upstreaming.
> I'd like that approach more too.
More information about the Linux-security-module-archive