On 7/10/2019 3:16 PM, Jarkko Sakkinen wrote:
Just some questions on these.
On Tue, Jul 09, 2019 at 10:09:17AM -0700, Sean Christopherson wrote:
- FILE__ENCLAVE_EXECUTE: equivalent to FILE__EXECUTE, required to gain X
on an enclave page loaded from a regular file
One thing that I have hard time to perceive is that whether the process
or the target object has them. So would this be in the files extended
attribute or does process need to possess this or both?
The target object.
- PROCESS2__ENCLAVE_EXECDIRTY: hybrid of EXECMOD and EXECUTE+WRITE,
required to gain W->X on an enclave page
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".
EXCLAVE_EXECDIRTY is similar to EXECMOD but because of his "maximal
protection" model, LSM couldn't distinguish between "W->X" and "X->W",
hence those two are collapsed into a single case - WX in "maximal
protection".
- 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
I guess these three belong to the process and are not attached to file.
Correct.
ENCLAVE_EXECANON basically means the calling process doesn't care what
permissions given to enclave pages as the SIGSTRUCT alone is considered
sufficient validation. This has a security impact process wide so shall
be a process permission.
ENCLAVE_{EXECDIRTY|MAPWX} express enclave specific
requirements/behaviors and IMO shall be enclave permissions, probably
manifested as file permissions on the file containing SIGSTRUCT. Sean
was taking a shortcut to make them process scope in order to avoid
keeping the SIGSTRUCT file around, which was what I criticized as
"illogical".
How in SELinux anyway process in the first place acquires any SELinux
permissions? I guess getty or whatever login process can set its perms
before setuid() et al somehow (I don't know how) because they run as
root?
/Jarkko
