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

[Xing, Cedric]

On 7/9/2019 10:09 AM, Sean Christopherson wrote:
> On Tue, Jul 09, 2019 at 07:22:03PM +0300, Jarkko Sakkinen wrote:
>> On Mon, Jul 08, 2019 at 10:29:30AM -0700, Sean Christopherson wrote:
>>> On Fri, Jul 05, 2019 at 07:05:49PM +0300, Jarkko Sakkinen wrote:
>>>> On Wed, Jun 19, 2019 at 03:23:49PM -0700, Sean Christopherson wrote:
>>>>
>>>> I still don't get why we need this whole mess and do not simply admit
>>>> that there are two distinct roles:
>>>>
>>>> 1. Creator
>>>> 2. User
>>>
>>> Because SELinux has existing concepts of EXECMEM and EXECMOD.
>>
>> What is the official documentation for those? I've only found some
>> explanations from discussions and some RHEL sysadmin guides.
> 
> No clue.  My knowledge was gleaned from the code and from Stephen's
> feedback.
> 
> 
> The high level breakdown:
> 
>    - FILE__EXECUTE: required to gain X on a mapping to a regular file
> 
> 
>    - FILE__EXECUTE + FILE__WRITE: required to gain WX or W->X on a shared
>                                   mapping to a regular file
> 
>    - FILE__EXECMOD: required to gain W->X on a private mapping of a regular
>                     file
> 
>    - PROCESS__EXECMEM: required to gain WX on a private mapping to a regular
>                        file, OR to gain X on an anonymous mapping.
> 
> 
> Translating those to SGX, with a lot of input from Stephen, I ended up
> with the following:
> 
>    - FILE__ENCLAVE_EXECUTE: equivalent to FILE__EXECUTE, required to gain X
>                             on an enclave page loaded from a regular file
> 
>    - PROCESS2__ENCLAVE_EXECDIRTY: hybrid of EXECMOD and EXECUTE+WRITE,
>                                   required to gain W->X on an enclave page

EXECMOD basically indicates a file containing self-modifying code. Your 
ENCLAVE_EXECDIRTY is however a process permission, which is illogical.

>    - 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
> 
> 
> 
>>> 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.
>>
>> I'd like that approach more too.
>>
>> /Jarkko