On Thu, Jul 11, 2019 at 10:32:41AM -0400, Stephen Smalley wrote: > The existing permissions don't map cleanly to SGX but I think Sean and > Cedric were trying to make a best-effort approximation to the underlying > concepts in a manner that permits control over the introduction of > executable content. > > Sure, the existing EXECMOD check is only applied today when there is an > attempt to make executable a previously modified (detected based on COW > having occurred) private file mapping. But the general notion of > controlling the ability to execute modified content is still meaningful. OK to summarize EXECMOD does not connect with SGX in any possible way but SGX needs something that mimics EXECMOD behaviour? And the same probably goes for EXECMEM, which is also private mapping related concept. > In the case of regular files, having both FILE__WRITE and FILE__EXECUTE to > the file is sufficient because that implies the ability to execute modified > content. And those FILE__* checks predated the introduction of EXECMOD and > EXECMEM. Right. > The mapping of /dev/sgx/enclave doesn't really fit existing categories > because it doesn't provide the same semantics as a shared mapping of a > regular file. Userspace will always need both FILE__WRITE and FILE__EXECUTE > to /dev/sgx/enclave. Right. Yeah, that has been the confusing part for me that they've been shuffled in the discussion together with SGX concepts and hooks like there was any connection. Thank you for clarifying this! /Jarkko
