From: Stephen Smalley [mailto:sds@tycho.nsa.gov]
Sent: Thursday, June 13, 2019 10:02 AM

On 6/11/19 6:02 PM, Sean Christopherson wrote:

quoted

On Tue, Jun 11, 2019 at 09:40:25AM -0400, Stephen Smalley wrote:

quoted

I haven't looked at this code closely, but it feels like a lot of
SGX-specific logic embedded into SELinux that will have to be
repeated or reused for every security module.  Does SGX not track

this state itself?

quoted

SGX does track equivalent state.

There are three proposals on the table (I think):

   1. Require userspace to explicitly specificy (maximal) enclave page
      permissions at build time.  The enclave page permissions are

provided

quoted

      to, and checked by, LSMs at enclave build time.

      Pros: Low-complexity kernel implementation, straightforward

auditing

quoted

      Cons: Sullies the SGX UAPI to some extent, may increase

complexity of

quoted

            SGX2 enclave loaders.

   2. Pre-check LSM permissions and dynamically track mappings to

enclave

quoted

      pages, e.g. add an SGX mprotect() hook to restrict W->X and WX
      based on the pre-checked permissions.

      Pros: Does not impact SGX UAPI, medium kernel complexity
      Cons: Auditing is complex/weird, requires taking enclave-

specific

quoted

            lock during mprotect() to query/update tracking.

   3. Implement LSM hooks in SGX to allow LSMs to track enclave

regions

quoted

      from cradle to grave, but otherwise defer everything to LSMs.

      Pros: Does not impact SGX UAPI, maximum flexibility, precise

auditing

quoted

      Cons: Most complex and "heaviest" kernel implementation of the

three,

quoted

            pushes more SGX details into LSMs.

My RFC series[1] implements #1.  My understanding is that Andy
(Lutomirski) prefers #2.  Cedric's RFC series implements #3.

Perhaps the easiest way to make forward progress is to rule out the
options we absolutely *don't* want by focusing on the potentially
blocking issue with each option:

   #1 - SGX UAPI funkiness

   #2 - Auditing complexity, potential enclave lock contention

   #3 - Pushing SGX details into LSMs and complexity of kernel
implementation


[1]
https://lkml.kernel.org/r/20190606021145.12604-1-sean.j.christopherson
@intel.com

Given the complexity tradeoff, what is the clear motivating example for
why #1 isn't the obvious choice? That the enclave loader has no way of
knowing a priori whether the enclave will require W->X or WX?  But
aren't we better off requiring enclaves to be explicitly marked as
needing such so that we can make a more informed decision about whether
to load them in the first place?

Are you asking this question at a) page granularity, b) file granularity or c) enclave (potentially comprised of multiple executable files) granularity?

#b is what we have on regular executable files and shared objects (i.e. FILE__EXECMOD). We all know how to do that.

#c is kind of new but could be done via some proxy file (e.g. sigstruct file) hence reduced to #b.

#a is problematic. It'd require compilers/linkers to generate such information, and proper executable image file format to carry that information, to be eventually picked up the loader. SELinux doesn't have PAGE__EXECMOD I guess is because it is generally considered impractical.

Option #1 however requires #a because the driver doesn't track which page was loaded from which file, otherwise it can no longer be qualified "simple". Or we could just implement #c, which will make all options simpler. But I guess #b is still preferred, to be aligned with what SELinux is enforcing today on regular memory pages.