From: Stephen Smalley <sds@tycho.nsa.gov>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
linux-security-module@vger.kernel.org, linux-sgx@vger.kernel.org,
x86@kernel.org
Cc: casey.schaufler@intel.com, jmorris@namei.org, luto@kernel.org,
sean.j.christopherson@intel.com
Subject: Re: LSM module for SGX?
Date: Thu, 27 Jun 2019 09:41:48 -0400 [thread overview]
Message-ID: <496ea018-2655-a438-bc6b-80330c36cd11@tycho.nsa.gov> (raw)
In-Reply-To: <320da9183c7e9ae2c63982d5e124054a615c4b99.camel@linux.intel.com>
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.
next prev parent reply other threads:[~2019-06-27 13:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-27 12:56 LSM module for SGX? Jarkko Sakkinen
2019-06-27 13:41 ` Stephen Smalley [this message]
2019-06-27 19:20 ` Xing, Cedric
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=496ea018-2655-a438-bc6b-80330c36cd11@tycho.nsa.gov \
--to=sds@tycho.nsa.gov \
--cc=casey.schaufler@intel.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jmorris@namei.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=luto@kernel.org \
--cc=sean.j.christopherson@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox