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@xxxxxxxxxxxxxxx/T/ and https://lore.kernel.org/linux-sgx/20200401084511.GE17325@xxxxxxxxxxxxxxx/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@xxxxxxxxxxxxxxx> 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
