On Wed, Jul 10, 2019 at 10:25 AM Sean Christopherson <sean.j.christopherson@xxxxxxxxx> wrote: > > On Tue, Jul 09, 2019 at 07:06:34PM +0300, Jarkko Sakkinen wrote: > > On Mon, Jul 08, 2019 at 09:19:32AM -0700, Sean Christopherson wrote: > > > > 2. Probably some "user story" type of examples would help with the > > > > discussion overall [1] i.e. how one would use this for > > > > her own good. > > > > > > The compelling story is Andy's original concern that userspace could > > > circumvent existing security policies by running code in an enclave. > > > > > > AIUI, closing the LSM loophole is the minimal requirement to get SGX > > > upstreamed. The extensive discussion has largely been focused on > > > ensuring that whatever mechanism is used to close the loophole will > > > play nice with future SGX functionality and/or LSM security policies. > > > > OK, might be getting here where I fall out of the wagon so: > > > > Doesn't Andy's example anyway require a process that has privileges to > > make pages executable i.e. it could run arbitrary code even without an > > enclave? > > Ah, no. He did raise that concern, but it'd only be an issue if the > enclave fd were backed by an anon inode, in which case all enclaves would > need EXECMEM in order to gain PROT_EXEC on EPC. Because the fd is backed > /dev/sgx/enclave, userspace just needs FILE__EXECUTE on /dev/sgx/enclave. I would say it differently: regardless of exactly how /dev/sgx/enclave is wired up under the hood, we want a way that a process can be granted permission to usefully run enclaves without being granted permission to execute whatever bytes of code it wants. Preferably without requiring LSMs to maintain some form of enclave signature whitelist. This is pretty much the only hard requirement I see. We really could achieve this, in a somewhat limited form, by saying that LSMs can approve or reject the SIGSTRUCT. But doing it that way is a bit nasty as we've noticed, for a few reasons. Several of you have raised objections to requiring SIGSTRUCT to come from a .sigstruct file. We also need to worry about a SIGSTRUCT that refers to an enclave that forgot to measure its text. And we need to worry about SGX2. So this whole messy exercise boils down to: a bunch of security policy authors think that EXECMEM and similar are not to be given out lightly. How to we allow policies like that to be compatible with SGX?
