On 7/11/19 5:26 AM, Jarkko Sakkinen wrote:
On Wed, Jul 10, 2019 at 04:16:42PM -0700, Xing, Cedric wrote:
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".
Looking at that part of code, there is this comment:
/*
* We are making executable a file mapping that has
* had some COW done. Since pages might have been
* written, check ability to execute the possibly
* modified content. This typically should only
* occur for text relocations.
*/
There is no COW done with enclaves, never. Thus, EXECMOD does not
connect in any possible way to SGX. OR, that comment is false.
Which one is it?
Also the official documentation for SELinux speaks only about COW
mappings.
Also the condition supports all this as a *private* file mapping ends up
to the anon_vma list when it gets written. We have a *shared* file
mapping
Nothing that you say makes sense to me, sorry...
The existing permissions don't map cleanly to SGX but I think Sean and
Cedric were trying to make a best-effort approximation to the underlying
concepts in a manner that permits control over the introduction of
executable content.
Sure, the existing EXECMOD check is only applied today when there is an
attempt to make executable a previously modified (detected based on COW
having occurred) private file mapping. But the general notion of
controlling the ability to execute modified content is still meaningful.
In the case of regular files, having both FILE__WRITE and FILE__EXECUTE
to the file is sufficient because that implies the ability to execute
modified content. And those FILE__* checks predated the introduction of
EXECMOD and EXECMEM.
The mapping of /dev/sgx/enclave doesn't really fit existing categories
because it doesn't provide the same semantics as a shared mapping of a
regular file. Userspace will always need both FILE__WRITE and
FILE__EXECUTE to /dev/sgx/enclave.
