On 7/11/19 11:12 AM, Sean Christopherson wrote:
On Thu, Jul 11, 2019 at 09:51:19AM -0400, Stephen Smalley wrote:
I'd also feel better if there was clear consensus among all of the
@intel.com participants that this is the right approach. To date that has
seemed elusive.
That's a very kind way to phrase things :-)
For initial upstreaming, we've agreed that there is no need to extend the
uapi, i.e. we can punt on deciding between on-the-fly tracking and having
userspace specify maximal permissions until we add SGX2 support.
The last open (knock on wood) for initial upstreaming is whether SELinux
would prefer to have new enclave specific permissions or reuse the
existing PROCESS__EXECMEM, FILE__EXECUTE and FILE__EXECMOD permissions.
My understanding is that enclave specific permissions are preferred.
I was left unclear on this topic after the email exchanges with Cedric.
There are at least three options:
1) Reuse the existing EXECMEM, EXECUTE, and EXECMOD permissions. Pros:
Existing distro policies will be applied in the expected manner with
respect to the introduction of executable code into the system,
consistent control will be provided over the enclave and the host
process, no change for users/documentation wrt policy. Cons: Existing
permissions don't map exactly to SGX semantics, no ability to
distinguish executable content within the enclave versus the host
process at the LSM level (argued earlier by Cedric to be unnecessary and
perhaps meaningless), need to allow FILE__EXECUTE or other checks on
sigstruct files that may not actually contain code.
2) Define new permissions within existing security classes (e.g.
process2, file). Pros: Can tailor permission names and definitions to
SGX semantics, ability to distinguish enclave versus host process
execute access, no need to grant FILE__EXECUTE to sigstruct files, class
matches the target object, permissions computed and cached upon existing
checks (i.e. when a process accesses a file, all of the permissions to
that file are computed and then cached at once, including the
enclave-related ones). Cons: Typical distro policies (unlike Android)
allow unknown permissions by default for forward kernel compatibility
reasons, so existing policies will permit these new permissions by
default and enforcement will only truly take effect once policies are
updated, adding new permissions to existing classes requires an update
to the base policy (so they can't be shipped as a third party policy
module alongside the SGX driver or installed as a local module by an
admin, for example), documentation/user education required for new
permissions.
3) Define new permissions in new security classes (e.g. enclave). Pros
relative to #2: New classes and permissions can be defined and installed
in third party or local policy module without requiring a change to the
base policy. Cons relative to #2: Class won't correspond to the target
object, permissions won't be computed and cached upon existing checks
(only when performing the checks against the new classes).
Combinations are also possible, of course.
