> From: Stephen Smalley [mailto:sds@xxxxxxxxxxxxx] > Sent: Thursday, June 13, 2019 10:02 AM > > On 6/11/19 6:02 PM, Sean Christopherson wrote: > > On Tue, Jun 11, 2019 at 09:40:25AM -0400, Stephen Smalley wrote: > >> 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? > > > > 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 > > to, and checked by, LSMs at enclave build time. > > > > Pros: Low-complexity kernel implementation, straightforward > auditing > > Cons: Sullies the SGX UAPI to some extent, may increase > complexity of > > SGX2 enclave loaders. > > > > 2. Pre-check LSM permissions and dynamically track mappings to > enclave > > 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 > > lock during mprotect() to query/update tracking. > > > > 3. Implement LSM hooks in SGX to allow LSMs to track enclave > regions > > from cradle to grave, but otherwise defer everything to LSMs. > > > > Pros: Does not impact SGX UAPI, maximum flexibility, precise > auditing > > Cons: Most complex and "heaviest" kernel implementation of the > three, > > 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.
