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