Re: [PATCH 2/4] x86/sgx: Put enclaves into anonymous files

[Topi Miettinen <toiwoton@gmail.com>]

On 4.4.2020 8.46, Jethro Beekman wrote:
> This appears to originate in Debian
> 
> Rationale: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/9
> 
> Interestingly, they claim mmap(/dev/zero) is special-cased? Can we do the same for SGX?
> 
> Some allowances were made in https://salsa.debian.org/kernel-team/initramfs-tools/-/commit/d6c6eeca3540d18f5bce95b5ffcb1823ab3050ea
> 
> Including those people in this conversation.
> 
> Ben, Towi: for context, see https://lore.kernel.org/linux-sgx/20200319142434.GA11305@linux.intel.com/T/ and https://lore.kernel.org/linux-sgx/20200401084511.GE17325@linux.intel.com/T/
> 
> --
> Jethro Beekman | Fortanix
> 
> On 2020-04-04 05:54, Andy Lutomirski wrote:
>>
>>
>>> On Apr 3, 2020, at 3:08 PM, Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote:
>>>
>>> On Fri, Apr 03, 2020 at 08:50:08AM -0700, Casey Schaufler wrote:
>>>>> How does smackfs interact with namespaces?
>>>>
>>>> Smack attributes are global. Aside from privilege issues, namespaces
>>>> ignore and are ignored by Smack.
>>>
>>> Okay.
>>>
>>> For SGX, I foresee things as:
>>>
>>> 1. Existing files are global.
>>> 2. If a policy of any kind is ever added it needs to be *per container*.
>>>    I'm not sure whether PID or user namespace is the right choice here,
>>>    but does not matter right now as the feature is not in the queue.
>>>
>>> To summarize:
>>>
>>> 1. We have a heterogeneous set of files (i.e. 'enclave' and 'provision'
>>>    are not "different sames").
>>> 2. The files probably will have heterogeneous visibility requirements.
>>>
>>> I think based on these premises own file system would be a more decent
>>> choice than populating /dev. Beside, SGX hasn't been a driver for a
>>> while.
>>>
>>> Andy, what do you think of this?
>>
>> Probably okay.  There are two semantic questions you’ll have to address, though:
>>
>> - What happens if you mount sgxfs twice?  Do you get two copies that can diverge from each other, or do you get two views of the same thing?
>>
>> - Can it be instantiated from outside the root initns?
>>
>> It’s certainly conceptually simpler to stick with device nodes. Why exactly is Ubuntu noexecing /dev?
>>
>>>
>>> /Jarkko
> 

My goal is to block executing binaries directly from /dev and using the 
file descriptors from device files to avoid EXECMEM, without relying on 
MACs. If the SGX device can be used to make new executable mappings, it 
should honor noexec for /dev. Then initramfs should make a similar 
exception as with v86d and grant exec to /dev. I think sgxfs should also 
honor noexec but it probably does not make sense to mount it so.

With an ioctl to SGX device the caller can change previously writable 
memory to executable. It should be able to trigger PROCESS__EXECMEM 
check for SELinux, so perhaps LSM hook for mprotect should be called:
https://github.com/intel/linux-sgx-driver/blob/95eaa6f6693cd86c35e10a22b4f8e483373c987c/sgx_ioctl.c#L254

Also SELinux reference policy doesn't know yet about SGX. Can the SGX 
enclave access physical memory, kernel memory or bypass MMU somehow even 
for the thread? If it can bypass SELinux protections, access should be 
conditional to boolean allow_raw_memory_access.

-Topi