[RFC PATCH v4 00/12] security: x86/sgx: SGX vs. LSM

[Sean Christopherson]

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
feedback.


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
                   file

  - 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
                                anonymous mapping
                       
  - PROCESS2__ENCLAVE_MAPWX: subset of EXECMEM, required to gain WX on an
                             enclave page



> > 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.
> 
> /Jarkko