> On Feb 18, 2020, at 2:43 AM, Dr. Greg Wettstein <gw@xxxxxxxxxxxx> wrote: > > On Mon, Feb 17, 2020 at 08:55:26PM +0200, Jarkko Sakkinen wrote: > > Good morning, I hope the week is starting well for everyone. > >>> On Mon, Feb 17, 2020 at 09:52:25AM +0100, Jethro Beekman wrote: >>> On 2020-02-15 08:24, Jarkko Sakkinen wrote: >>>> On Thu, Feb 13, 2020 at 03:10:24PM +0100, Jethro Beekman wrote: >>>>>>> There are other scenarios where it's not just the permissions on >>>>>>> /dev/sgx/enclave that are the problem but using the filesystem in general >>>>>>> that is. Maybe you've used seccomp to disable file operations, etc. >>>>>> >>>>>> Andy and Jarkko, thoughts? >>>>> >>>>> Folks, any more thoughts on how to resolve the issue that you need to >>>>> call open() for every enclave? >>>> >>>> Why is it an issue? >>> >>> Already discussed in https://www.spinics.net/lists/linux-sgx/msg02075.html > > I believe an accurate summary of Dr. Beekman's concerns are as > follows: > > 1.) He envisions a need for an enclave orchestrator that uses root > privileges to open the SGX driver device and then drop privileges, > presumably in a permanent fashion. The orchestrator would then use > the filehandle to load and initialize multiple enclaves on request. > > 2.) The enclave orchestrator may be run in an environment that has > SECCOMP limitations on the ability to conduct filesystem operations. > >> Not everyone has to have access to open /dev/sgx/enclave in order to >> use enclaves. > > That depends on the architecture of the runtime. > > The Intel PSW has a model where the AESM daemon orchestrates > activities for applications that wish to use enclaves. > > Our Secure Runtime Development Environment (SRDE), on the other hand, > uses a model where each application independently manages its use of > enclaves. In our model, the SGX driver needs to be accessible by > whatever privilege level an application chooses to run at. > > As a result of this model, our SRDE has around an order of magnitude > less complexity then the AESM model and virtually no external > dependencies. At last count the AESM depends on about 35 separate > shared library systems. > > Our model allows us to build applications that are statically linked > and completely self-contained. A concept of reasonable utility for > containerized environments and embedded systems. We also avoid C++ > that allows us to build MUSL based security stacks. > >> It is as much a problem as for practically any driver that provides >> devices for some use. > > The only customers of this driver are the runtime developers and that > is currently an extremely limited spectrum of users. > > I will concede that I don't understand the SECCOMP issue. Jethro may > or may not be able to discuss an architecture that would not have > basic filesystem operations available to it. Jethro, is there a way you could use SCM_RIGHTS to solve your problem? In principle, the driver could allow an enclave fd that isn’t ECREATEd yet to be forked with an ioctl, but ISTM this is extra complexity and there should be a well understood use case before something like this is added. > > The fundamental issue, that there appears to be a reluctance to > discuss, is that DAC/MAC controls are not relevant to SGX, > particularly SGX2 based systems, which is what most of this stuff > will be running on. > No, this isn’t the fundamental issue, because DAC/MAC is just as relevant to systems with SGX and SGX2. I’m sure that there will be systems that work with SGX and with everything running as root (or even SGX on a kernel without access control at all), but these will be a minority. Even if you have absolutely perfect protection of sensitive data, you sacrifice any sort of defense in depth against an attacker DoSing you in any number of amazing ways. Or, for that matter, leaking keys derived from the provisioning key. (Don’t forget that, no matter how carefully your system might lock down the SGXPUBKEYHASH MSRs and control the associated keys, that lockdown is being done by non-enclave *software*, and a bad guy who gets root is quite likely to be able to unlock the registers by upgrading their root access to control the firmware. Or get a launch token that can’t be revoked because SGX doesn’t have a token expiration mechanism.) No one wants to discuss your DAC-less model because, as far as I can tell, no one agrees with you. >> /Jarkko > > Have a good day. > > Dr. Greg > > As always, > Dr. Greg Wettstein, Ph.D Worker / Principal Engineer > IDfusion, LLC > 4206 19th Ave N. Specialists in SGX secured infrastructure. > Fargo, ND 58102 > PH: 701-281-1686 CELL: 701-361-2319 > EMAIL: gw@xxxxxxxxxxxx > ------------------------------------------------------------------------------ > "... remember that innovation is saying 'no' to 1000 things." > -- Moxie Marlinspike
