[RFC PATCH v4 10/12] security/selinux: Add enclave_load() implementation

[Xing, Cedric]

> From: linux-sgx-owner at vger.kernel.org [mailto:linux-sgx-
> owner at vger.kernel.org] On Behalf Of Stephen Smalley
> Sent: Tuesday, June 25, 2019 2:10 PM
> 
> On 6/21/19 5:22 PM, Xing, Cedric wrote:
> >> From: Christopherson, Sean J
> >> Sent: Wednesday, June 19, 2019 3:24 PM
> >>
> >> Intended use of each permission:
> >>
> >>    - SGX_EXECDIRTY: dynamically load code within the enclave itself
> >>    - SGX_EXECUNMR: load unmeasured code into the enclave, e.g.
> >> Graphene
> >
> > Why does it matter whether a code page is measured or not?
> 
> It won't be incorporated into an attestation?

Yes, it will. And because of that, I don't think LSM should care.

> 
> >
> >>    - SGX_EXECANON: load code from anonymous memory (likely Graphene)
> >
> > Graphene doesn't load code from anonymous memory. It loads code
> dynamically though, as in SGX_EXECDIRTY case.
> 
> So do we expect EXECANON to never be triggered at all?

I don't think so. And from security perspective, the decision I think shall base on whether the source pages are (allowed to be made) executable. 

> 
> >
> >>    - SGX_EXECUTE: load an enclave from a file, i.e. normal behavior
> >
> > Why is SGX_EXECUTE needed from security perspective? Or why isn't
> FILE__EXECUTE sufficient?
> 
> Splitting the SGX permissions from the regular ones allows distinctions
> to be made between what can be executed in the host process and what can
> be executed in the enclave.  The host process may be allowed
> FILE__EXECUTE to numerous files that do not contain any code ever
> intended to be executed within the enclave.

Given an enclave and its host process, any executable contents could be allowed in
1) Neither the enclave nor the host
2) Enclave only
3) Host only
4) Both the enclave and the host

Given the fact that enclave can access host's memory, if a piece of code is NOT allowed in the host, then it shouldn't be allowed in enclave either. So #2 shall never happen.

An enclave dictates/enforces its own contents cryptographically, so it's unnecessary to enforce #3 by LSM IMO.

Then #1 and #4 are the only 2 cases to be supported - a single FILE__EXECUTE is sufficient.

I'm not objecting to new permissions to make things more explicit, but that'd require updates to user mode tools. I think it just easier to reuse existing permissions.