Some LSM and SGX remarks before parting of for two weeks
Jarkko Sakkinen
jarkko.sakkinen at linux.intel.com
Fri Jul 12 02:10:55 UTC 2019
Before going to a two week vacation (sending v21 today), I'll make some
remarks on SGX and LSM's:
1. Currently all patch sets proposing LSM changes are missing a problem
statement and describe a solution to an undescribed problem.
2. When speaking of SELinux I haven't seen any draft's on how would
define a policy module with the new constructs. Does not have to
be a full policy modules but more like snippets demosntrating that
"this would work".
3. All the SELinux discussion is centered on type based policies.
Potentially one could isolate enclaves with some UBAC or RBAC
based model. That could be good first step and might not even
require LSM changes. Type based models could be introduced
post upstreaming. No deep analysis on this, but at least this
option should ruled out at minimum before striving into type
based security model.
I guess the problem statement is more or less that since with DAC you
would have to allow to use mmap() and mprotect() to change anything
to X, even to the point that you can do WX, one needs a MAC to
somehow fix this.
Was not that hard, was it? Should be refined though with some context
why SGX requires this to not so SGX-oriented audience.
Even with just DAC this could be potentially sorted out with UBAC or
RBAC based solution e.g. have an SGID for enclave "builders" and the
device itself.
Repeating myself but type based security can be always added
aftewards.
/Jarkko
More information about the Linux-security-module-archive
mailing list