> From: linux-sgx-owner@xxxxxxxxxxxxxxx [mailto:linux-sgx- > owner@xxxxxxxxxxxxxxx] On Behalf Of Stephen Smalley > Sent: Thursday, June 27, 2019 6:42 AM > > On 6/27/19 8:56 AM, Jarkko Sakkinen wrote: > > Looking at the SGX-LSM discussions I haven't seen even a single email > > that would have any conclusions that the new hooks are the only > possible > > route to limit the privileges to use SGX. > > > > An obvious alternative to consider might be to have a small-scale LSM > > that you could stack. AFAIK Casey's LSM stacking patch set has not yet > > landed but I also remember that with some constraints you can still do > > it. Casey explained these constraints to me few years ago but I can't > > recall them anymore :-) > > > > One example of this is Yama, which limits the use of ptrace(). You can > > enable it together with any of the "big" LSMs in the kernel. > > > > A major benefit in this approach would that it is non-intrusive when > it > > comes to other architectures than x86. New hooks are not only > > maintenance burden for those who care about SGX but also for those who > > have to deal with LSMs. > > Regardless of whether or not you or anyone else creates such a > small-scale LSM, we would still want to be able to control the loading > of enclaves and the creation of executable enclave mappings via SELinux > policy, so the hooks would be necessary anyway. Just want to add that, no matter it is incorporated into a big or separated into a small LSM module, hooks are always necessary. The difference is just which LSM module registers for those hooks.
