On 6/27/19 4:19 PM, Xing, Cedric wrote:
From: linux-sgx-owner@xxxxxxxxxxxxxxx [mailto:linux-sgx-
owner@xxxxxxxxxxxxxxx] 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).
