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

From: Stephen Smalley <sds@tycho.nsa.gov>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	"Xing, Cedric" <cedric.xing@intel.com>
Cc: Sean Christopherson <sean.j.christopherson@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>,
	"Dr . Greg Wettstein" <greg@enjellic.com>
Subject: Re: [RFC PATCH v4 00/12] security: x86/sgx: SGX vs. LSM
Date: Thu, 11 Jul 2019 10:32:41 -0400	[thread overview]
Message-ID: <ef0c9052-d22e-aaa6-4915-b1823abea64c@tycho.nsa.gov> (raw)
In-Reply-To: <20190711092609.jxe4uubwg5qbwfju@linux.intel.com>

On 7/11/19 5:26 AM, Jarkko Sakkinen wrote:
> On Wed, Jul 10, 2019 at 04:16:42PM -0700, Xing, Cedric wrote:
>>> Still puzzling with EXECMOD given that how it is documented in
>>> https://selinuxproject.org/page/ObjectClassesPerms. If anything in that
>>> document is out of date, would be nice if it was updated.
>>
>> If you search for "EXECMOD" in security/selinux/hooks.c in the latest
>> (Linux-5.2) master, you'll find only one occurrence - at line 3702.
>>
>> The logic over there, if translated into English, basically says
>> FILE__EXECMOD is required (on the backing file) if mprotect() is called to
>> request X on a private file mapping that has been modified by the calling
>> process. That's what Sean meant by "W->X".
> 
> Looking at that part of code, there is this comment:
> 
> /*
>   * We are making executable a file mapping that has
>   * had some COW done. Since pages might have been
>   * written, check ability to execute the possibly
>   * modified content.  This typically should only
>   * occur for text relocations.
>   */
> 
> There is no COW done with enclaves, never. Thus, EXECMOD does not
> connect in any possible way to SGX. OR, that comment is false.
> 
> Which one is it?
> 
> Also the official documentation for SELinux speaks only about COW
> mappings.
> 
> Also the condition supports all this as a *private* file mapping ends up
> to the anon_vma list when it gets written. We have a *shared* file
> mapping
> 
> Nothing that you say makes sense to me, sorry...

The existing permissions don't map cleanly to SGX but I think Sean and 
Cedric were trying to make a best-effort approximation to the underlying 
concepts in a manner that permits control over the introduction of 
executable content.

Sure, the existing EXECMOD check is only applied today when there is an 
attempt to make executable a previously modified (detected based on COW 
having occurred) private file mapping.  But the general notion of 
controlling the ability to execute modified content is still meaningful.

In the case of regular files, having both FILE__WRITE and FILE__EXECUTE 
to the file is sufficient because that implies the ability to execute 
modified content.  And those FILE__* checks predated the introduction of 
EXECMOD and EXECMEM.

The mapping of /dev/sgx/enclave doesn't really fit existing categories 
because it doesn't provide the same semantics as a shared mapping of a 
regular file.  Userspace will always need both FILE__WRITE and 
FILE__EXECUTE to /dev/sgx/enclave.