lkml.org 
[lkml]   [2019]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2019-09-14 15:43    [W:0.956 / U:0.676 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site