Re: [PATCH v20 00/28] Intel SGX1 support

["Dr. Greg" <greg@enjellic.com>]

On Sat, Apr 20, 2019 at 07:42:13AM +0200, Thomas Gleixner wrote:

Good morning/weekend to everyone.

> On Fri, 19 Apr 2019, Jethro Beekman wrote:
> > On 2019-04-19 14:34, Thomas Gleixner wrote:
> > > And how so? You create writeable AND executable memory. That's a nono and
> > > you can argue in circles, that's not going to change with any of your
> > > proposed changes.

> > On 2019-04-19 14:38, Thomas Gleixner wrote:
> > > You are working around LSM nothing else and that's just not going to fly.
> > 
> > Based on your comments, I'm still unsure if we're on the same page with
> > regards to what I'm proposing.
> > 
> > Here's a regular non-SGX flow that LSM would likely prevent:
> > 
> > mmap(PROT_READ|PROT_WRITE)
> > memcpy()
> > mmap(PROT_READ|PROT_EXEC) <-- denied by LSM
> > 
> > Or just something based on regular PT permissions:
> > 
> > mmap(PROT_READ|PROT_EXEC)
> > memcpy() <-- SIGSEGV
> > 
> > Now, the equivalent for SGX:
> > 
> > mmap(PROT_READ|PROT_WRITE)
> > ioctl(EADD)
> > mmap(PROT_READ|PROT_EXEC) <-- denied by LSM

> This is completely irrelevant, really.
>
> The point is that the SGX driver loads and executes arbitrary data
> which is handed in from user space via an ioctl w/o any chance of
> verifying where that comes from.
>
> What Andy proposed is to open a file with the SGX payload and hand
> in the file descriptor. That way LSM can decide whether this is
> allowed or denied based on the file descriptor and whatever the
> security model/policy is in a particular setup.
>
> Right know the SGX driver and its proposed API prevent any form of
> LSM auditing and whatever permission checks you had in mind won't
> change that at all.

I don't even want to remotely get in the middle of this arguement,
since we are probably already persona-non-grata for having stimulated
a discussion that has slowed upstreaming, but some comments to assist
and clarify further progress on the driver.

We understand and support the need for the LSM to trap these events,
but what does LSM provenance mean if the platform is compromised?
That is, technically, the target application for SGX technology.

This issue is what drove our concern for having ring-0 based
enforcement of who can initialize an enclave.  As Andy has pointed
out, the mmap semantics of the SGX driver allow the introduction of
executable code that bypasses LSM enforcement, but the platform owner,
with appropriate enforcements on an FLC platform, has cryptographic
verification and trust for the origin and provenance of that executable
code.

It may be possible to load the executable code into enclave memory but
the processor will refuse to access the memory until the EINIT
instruction validates that the loaded code is compliant with the
enclave metadata and measurement.  That is why we were argueing for,
simple, ring-0 based verification of the key signature that authorizes
the EINIT instruction to complete.

From a more practical perspective, an enclave shared image is a rather
complex beast, that contains a lot of metadata.  An application has to
open the shared image file and parse the metadata in order to properly
construct the enclave image from the text in the image file.  I
believe in practice that will effectively activate LSM recognition of
the executable code.

That obviously leaves a cunning adversary an opportunity to teleport a
simple binary file or network stream onto a platform and load and
execute the contents.  But that takes us back to the need for ring-0
enforcement of enclave initialization... :-)

We wrote a major enhancement to the Linux IMA architecture to
implement introspection of behavioral namespaces.  The actor/subject
events get forwarded up into a modeling engine running inside of a
namespace specific SGX enclave instance that issues a system call to
instruct an LSM that we wrote, and that pairs with the IMA extension,
to 'discipline' the process if it is acting outside its behavioral
specification.

We will verify with Jarkko's current HEAD, but I believe it is
consistently trapping access to the shared image file and hence the
text of the enclave.

> Thanks,
> 
> 	tglx

Have a good weekend.

Dr. Greg

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"Simplicity is prerequisite for reliability."
                                -- Edsger W. Dijkstra