> On Sep 15, 2019, at 10:24 PM, Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx> wrote: > > 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. As the person who originally raised the issue, I feel like I should rehash the issue: Right now, using SELinux or probably other LSMs, it's straightforward to prevent programs from having any executable pages whose contents doesn't come from an approved (e.g. appropriately labeled) source. With /dev/sgx/enclave, at least as initially designed, a process that can open /dev/sgx/enclave can execute whatever bytes they want by sticking them into an enclave. I fully expect that people will want to combine these things: have unprivileged users run only admin-approved code but *also* allow unprivileged users to run enclaves. > *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. The latter is very much like the labeled-enclave-file thing we talked about. > > I think either can be considered post-upstreaming. Indeed, as long as the overall API is actually compatible with these types of restrictions.
