linux-kernel - Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190530222423.GD27551@linux.intel.com>
Date:   Thu, 30 May 2019 15:24:23 -0700
From:   Sean Christopherson <sean.j.christopherson@...el.com>
To:     "Xing, Cedric" <cedric.xing@...el.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Stephen Smalley <sds@...ho.nsa.gov>,
        William Roberts <bill.c.roberts@...il.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        LSM List <linux-security-module@...r.kernel.org>,
        Paul Moore <paul@...l-moore.com>,
        Eric Paris <eparis@...isplace.org>,
        "selinux@...r.kernel.org" <selinux@...r.kernel.org>,
        Jethro Beekman <jethro@...tanix.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Dr. Greg" <greg@...ellic.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        "linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "npmccallum@...hat.com" <npmccallum@...hat.com>,
        "Ayoun, Serge" <serge.ayoun@...el.com>,
        "Katz-zamir, Shay" <shay.katz-zamir@...el.com>,
        "Huang, Haitao" <haitao.huang@...el.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        "Svahn, Kai" <kai.svahn@...el.com>, Borislav Petkov <bp@...en8.de>,
        Josh Triplett <josh@...htriplett.org>,
        "Huang, Kai" <kai.huang@...el.com>,
        David Rientjes <rientjes@...gle.com>
Subject: Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

On Thu, May 30, 2019 at 02:48:43PM -0700, Xing, Cedric wrote:
> So I think the same rationale applies to enclaves. Your original idea of
> MAXPERM is the policy set forth by system admin and shall *never* change at
> runtime. If an enclave is dynamically linked and needs to bring in code pages
> at runtime, the admin needs to enable it by setting, say ENCLAVE__EXECMOD, in
> the sigstruct file. Then all EAUG'ed pages will receive RWX as MAXPERM. The
> process would then mprotect() selective pages to be RX but which exact set of
> pages doesn't concern LSM usually.

Because passing RWX means the enclave "requires" EXECMOD even if it never
actually does a RW->RX transition.  It's not broken per se, but at the
very least it's decidedly odd.

Dynamically detecting the EXECMOD case is not difficult and has the
advantage of simplifying userspace loaders, e.g. all EAUG pages are tagged
ALLOW_WRITE and the kernel takes care of the rest.

I *think* auditing/learning is also messed up with a MAXPERMS approach, as
mprotect() would fail (due to MAXPERMS clearing MAY_{READ,WRITE,EXEC})
before it calls security_file_mprotect().  Hooking mprotect() is the
obvious workaround, but then it's looking a lot like the new proposals.

In other words, the new proposals are rooted in the MAXPERMS concept, e.g.
MAXPERM is effectively "I want EXECMOD", which gets distilled down to
ALLOW_WRITE (or ALLOW_EXEC in Andy's proposal).