linux-kernel - Re: [PATCH v22 00/24] Intel SGX foundations

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: <20190914134136.GG9560@linux.intel.com>
Date:   Sat, 14 Sep 2019 14:41:36 +0100
From:   Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
To:     Dave Hansen <dave.hansen@...el.com>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org,
        linux-sgx@...r.kernel.org, akpm@...ux-foundation.org,
        sean.j.christopherson@...el.com, nhorman@...hat.com,
        npmccallum@...hat.com, serge.ayoun@...el.com,
        shay.katz-zamir@...el.com, haitao.huang@...el.com,
        andriy.shevchenko@...ux.intel.com, tglx@...utronix.de,
        kai.svahn@...el.com, bp@...en8.de, josh@...htriplett.org,
        luto@...nel.org, kai.huang@...el.com, rientjes@...gle.com,
        cedric.xing@...el.com
Subject: Re: [PATCH v22 00/24] Intel SGX foundations

On Fri, Sep 13, 2019 at 01:38:18PM -0700, Dave Hansen wrote:
> On 9/3/19 7:26 AM, Jarkko Sakkinen wrote:
> > Not having LSM hooks does not cause any risk to other parts of the
> > kernel as the device can still be controlled by using DAC permissions.
> > The hooks just provide more granularity than DAC in access decisions.
> 
> Could we translate the security-speak to english, please? :)
> 
> Is this it:
> 
> 	LSMs can (try to) enforce things like "all executable code must
> 	be verified".  The implementation in these patches has the
> 	potential to subvert policies like that since it has its own
> 	unique mechanisms for loading and mapping executable code.  This
> 	will be fixed by future LSM enhancements on top of this set.
> 	For now, permissions on the SGX device file should be used to
> 	prevent untrusted users from using SGX to subvert LSM policies.

I'm not sure what "security-speak" is but lets try plain English and
see where we get from there.

The proposed LSM hooks give the granularity to make yes/no decision
based on the

* The origin of the source of the source for the enclave.
* The requested permissions for the added or mapped peage.

The hooks to do these checks are provided for mmap() and EADD
operations.

With just file permissions you can still limit mmap() by having a
privileged process to build the enclaves and pass the file descriptor
to the enclave user who can mmap() the enclave within the constraints
set by the enclave pages (their permissions refine the roof that you
can mmap() any memory range within an enclave).

/Jarkko