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

From: "Xing, Cedric" <cedric.xing@intel.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Sean Christopherson <sean.j.christopherson@intel.com>
Cc: 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>,
	Stephen Smalley <sds@tycho.nsa.gov>
Subject: Re: [RFC PATCH v4 00/12] security: x86/sgx: SGX vs. LSM
Date: Wed, 10 Jul 2019 16:16:42 -0700	[thread overview]
Message-ID: <38d3b0ee-be9c-cb1a-785a-325a3ade003b@intel.com> (raw)
In-Reply-To: <20190710221638.bwnwtcozpv44ojdg@linux.intel.com>

On 7/10/2019 3:16 PM, Jarkko Sakkinen wrote:
> Just some questions on these.
> 
> On Tue, Jul 09, 2019 at 10:09:17AM -0700, Sean Christopherson wrote:
>>    - FILE__ENCLAVE_EXECUTE: equivalent to FILE__EXECUTE, required to gain X
>>                             on an enclave page loaded from a regular file
> 
> One thing that I have hard time to perceive is that whether the process
> or the target object has them. So would this be in the files extended
> attribute or does process need to possess this or both?

The target object.

>>    - PROCESS2__ENCLAVE_EXECDIRTY: hybrid of EXECMOD and EXECUTE+WRITE,
>>                                   required to gain W->X on an enclave page
> 
> 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".

EXCLAVE_EXECDIRTY is similar to EXECMOD but because of his "maximal 
protection" model, LSM couldn't distinguish between "W->X" and "X->W", 
hence those two are collapsed into a single case - WX in "maximal 
protection".

>>    - PROCESS2__ENCLAVE_EXECANON: subset of EXECMEM, required to gain X on
>>                                  an enclave page that is loaded from an
>>                                  anonymous mapping
>>
>>    - PROCESS2__ENCLAVE_MAPWX: subset of EXECMEM, required to gain WX on an
>>                               enclave page
> 
> I guess these three belong to the process and are not attached to file.

Correct.

ENCLAVE_EXECANON basically means the calling process doesn't care what 
permissions given to enclave pages as the SIGSTRUCT alone is considered 
sufficient validation. This has a security impact process wide so shall 
be a process permission.

ENCLAVE_{EXECDIRTY|MAPWX} express enclave specific 
requirements/behaviors and IMO shall be enclave permissions, probably 
manifested as file permissions on the file containing SIGSTRUCT. Sean 
was taking a shortcut to make them process scope in order to avoid 
keeping the SIGSTRUCT file around, which was what I criticized as 
"illogical".

> How in SELinux anyway process in the first place acquires any SELinux
> permissions? I guess getty or whatever login process can set its perms
> before setuid() et al somehow (I don't know how) because they run as
> root?
> 
> /Jarkko
> 