Re: [PATCH v22 00/24] Intel SGX foundations

[Jarkko Sakkinen]

On Sat, Sep 14, 2019 at 08:32:38AM -0700, Dave Hansen wrote:
> On 9/14/19 6:41 AM, Jarkko Sakkinen wrote:
> > 
> > The proposed LSM hooks give the granularity to make yes/no decision
> > based on the
> > 
> > * The origin of the source of the source for the enclave.
> > * The requested permissions for the added or mapped peage.
> > 
> > The hooks to do these checks are provided for mmap() and EADD
> > operations.
> > 
> > With just file permissions you can still limit mmap() by having a
> > privileged process to build the enclaves and pass the file descriptor
> > to the enclave user who can mmap() the enclave within the constraints
> > set by the enclave pages (their permissions refine the roof that you
> > can mmap() any memory range within an enclave).
> 
> The LSM hooks are presumably fixing a problem that these patches
> introduce.  What's that problem?

I've seen the claims that one would have to degrade one's LSM policy but
I don't think that is true.

With just UNIX permissions you have probably have to restrict the access
to /dev/sgx/enclave to control who can build enclaves. The processes who
do not have this privilege can mmap() the enclave once they get the file
descriptor through forking or SCM_RIGHTS.

After SGX_IOC_ENCLAVE_INIT, the memory layout is sealed and the client
process can only use the enclave.

Further, we have /dev/sgx/provision to restrict, which enclaves can
attest themselves to a remote party.

*If anything*, I would rather investigate possibility to use keyring for
enclave signer's public keys or perhaps having extended attribute for
the signer (SHA256) in the enclave file that could be compared during
the EINIT.

I think either can be considered post-upstreaming.

/Jarkko