Re: [RFC PATCH v4 00/12] security: x86/sgx: SGX vs. LSM

From: "Xing, Cedric" <cedric.xing@intel.com>
To: "Dr. Greg" <greg@idfusion.net>,
	Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	linux-sgx@vger.kernel.org, linux-security-module@vger.kernel.org,
	selinux@vger.kernel.org,
	Bill Roberts <william.c.roberts@intel.com>,
	Casey Schaufler <casey.schaufler@intel.com>,
	James Morris <jmorris@namei.org>,
	Dave Hansen <dave.hansen@intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	Jethro Beekman <jethro@fortanix.com>,
	Stephen Smalley <sds@tycho.nsa.gov>
Subject: Re: [RFC PATCH v4 00/12] security: x86/sgx: SGX vs. LSM
Date: Tue, 9 Jul 2019 19:04:35 -0700	[thread overview]
Message-ID: <120cfcee-af82-83cd-fb73-a39ecddff2af@intel.com> (raw)
In-Reply-To: <20190710012811.GA18755@wind.enjellic.com>

On 7/9/2019 6:28 PM, Dr. Greg wrote:
> On Mon, Jul 08, 2019 at 10:29:30AM -0700, Sean Christopherson wrote:
> 
> Good evening to everyone.
> 
>> That being said, we can do so without functional changes to the SGX
>> uapi, e.g. add reserved fields so that the initial uapi can be
>> extended *if* we decide to go with the "userspace provides maximal
>> protections" path, and use the EPCM permissions as the maximal
>> protections for the initial upstreaming.
>>
>> That'd give us a minimal implemenation for initial upstreaming and
>> would eliminate Cedric's blocking complaint.  The "whole mess" of
>> whitelisting, blacklisting and SGX2 support would be deferred until
>> post-upstreaming.
> 
> Are we convinced the 'mess' will be any easier to clean up after the
> driver is upstreamed?
> 
> The primary problem is that we haven't addressed the issue of what
> this technology is designed to do and its implications with respect to
> the kernel.  As a result we are attempting to implement controls which
> we are comfortable with and understand rather then those that are
> relevant.

I don't think it's about easier or harder to clean up the mess, but a 
divide-and-conquer strategy. After all, SGX and LSM are kind of 
orthogonal as long as SGX doesn't compromise the protection provided by LSM.

Let's step back and look at what started this lengthy discussion. The 
primary problem of v20 was that the SGX module allows executable enclave 
pages to be created from non-executable regular pages, which could be 
exploited by adversaries to grant executable permissions to pages that 
would otherwise be denied without SGX. And that could be fixed simply by 
capping EPCM permissions to whatever allowed on the source page, without 
touching LSM. Of course the drawback is loss of functionality - i.e. 
self-modifying enclaves cannot be loaded unless the calling process has 
EXECMEM. But that should suffice, as most SGX1 applications don't 
contain self-modifying code anyway.

Then we could switch our focus back to LSM and work out what's relevant, 
especially for SGX2 and beyond.

> Have a good evening.
> 
> Dr. Greg
> 
> As always,
> Dr. Greg Wettstein, Ph.D, Worker
> IDfusion, LLC               Implementing SGX secured and modeled
> 4206 N. 19th Ave.           intelligent network endpoints.
> Fargo, ND  58102
> PH: 701-281-1686            EMAIL: greg@idfusion.net
> ------------------------------------------------------------------------------
> "Courage is not the absence of fear, but rather the judgement that
>   something else is more important than fear."
>                                  -- Ambrose Redmoon
> 