LSM module for SGX?

[Xing, Cedric]

> From: linux-sgx-owner at vger.kernel.org [mailto:linux-sgx-
> owner at vger.kernel.org] 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.