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

[Stephen Smalley]

On 6/27/19 4:19 PM, Xing, Cedric wrote:
>> 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.

FWIW, adding new permissions only requires updating policy 
configuration, not userspace code/tools.  But in any event, we can reuse 
the execute-related permissions if it makes sense but still consider 
introducing additional, new permissions, possibly in a separate 
"enclave" security class, if we want explicit control over enclave 
loading, e.g. ENCLAVE__LOAD, ENCLAVE__INIT, etc.

One residual concern I have with the reuse of FILE__EXECUTE is using it 
for the sigstruct file as the fallback case.  If the sigstruct is always 
part of the same file as the code, then it probably doesn't matter.  But 
otherwise, it is somewhat odd to have to allow the host process to 
execute from the sigstruct file if it is only data (the signature).