LSM module for SGX?

LSM module for SGX?

[Jarkko Sakkinen]

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.

/Jarkko

Re: LSM module for SGX?

[Stephen Smalley]

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.

RE: LSM module for SGX?

[Xing, Cedric]

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