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. 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. > /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
