Hi Dave, > On 5/10/19 10:37 AM, Jethro Beekman wrote: > > It does assume a specific format, namely, that the memory layout > > (including page types/permissions) of the enclave can be represented > in > > a "flat file" on disk, or at least that the enclave memory contents > > consist of 4096-byte chunks in that file. > > I _think_ Cedric's point is that, to the kernel, > /lib/x86_64-linux-gnu/libc.so.6 is a "flat file" because the kernel > doesn't have any part in parsing the executable format of a shared > library. > > I actually don't know how it works, though. Do we just just trust that > the userspace parsing of the .so format is correct? Do we just assume > that any part of a file passing IMA checks can be PROT_EXEC?
The key idea here is for enclave files to "inherit" the checks applicable to regular shared objects. And how we are going to do it is for user process to map every loadable segment of the enclave file into its address space using *multiple* mmap() calls, just in the same way as dlopen() would do for loading regular shared objects. Then those open()/mmap() syscalls will trigger all applicable checks (by means of security_file_open(), security_mmap_file() and ima_file_mmap() hooks) transparently. That said, IMA/LSM implementations/policies will dictate the success/failure of those open()/mmap() syscalls. And by depending EPCM attributes on permissions of source VMAs, no EXEC page could be ever created unless the source page (which has to be EXEC, btw) has passed IMA/LSM checks (as if it were loaded from a regular shared object file). -Cedric
