Some LSM and SGX remarks before parting of for two weeks

Some LSM and SGX remarks before parting of for two weeks

[Jarkko Sakkinen]

Before going to a two week vacation (sending v21 today), I'll make some
remarks on SGX and LSM's:

1. Currently all patch sets proposing LSM changes are missing a problem
   statement and describe a solution to an undescribed problem.
2. When speaking of SELinux I haven't seen any draft's on how would
   define a policy module with the new constructs. Does not have to
   be a full policy modules but more like snippets demosntrating that
   "this would work".
3. All the SELinux discussion is centered on type based policies.
   Potentially one could isolate enclaves with some UBAC or RBAC
   based model. That could be good first step and might not even
   require LSM changes. Type based models could be introduced
   post upstreaming. No deep analysis on this, but at least this
   option should ruled out at minimum before striving into type
   based security model.

I guess the problem statement is more or less that since with DAC you
would have to allow to use mmap() and mprotect() to change anything
to X, even to the point that you can do WX, one needs a MAC to
somehow fix this.

Was not that hard, was it? Should be refined though with some context
why SGX requires this to not so SGX-oriented audience.

Even with just DAC this could be potentially sorted out with UBAC or
RBAC based solution e.g. have an SGID for enclave "builders" and the
device itself.

Repeating myself but type based security can be always added
aftewards.

/Jarkko

Re: Some LSM and SGX remarks before parting of for two weeks

[James Morris]

On Fri, 12 Jul 2019, Jarkko Sakkinen wrote:

> Before going to a two week vacation (sending v21 today), I'll make some
> remarks on SGX and LSM's:
> 
> 1. Currently all patch sets proposing LSM changes are missing a problem
>    statement and describe a solution to an undescribed problem.
> 2. When speaking of SELinux I haven't seen any draft's on how would
>    define a policy module with the new constructs. Does not have to
>    be a full policy modules but more like snippets demosntrating that
>    "this would work".
> 3. All the SELinux discussion is centered on type based policies.
>    Potentially one could isolate enclaves with some UBAC or RBAC
>    based model. That could be good first step and might not even
>    require LSM changes.

Unless I misunderstand what you mean here, RBAC and UBAC in SELinux still 
require LSM hooks, and are typically integrated with Type Enforcement.



-- 
James Morris
<jmorris@namei.org>

Re: Some LSM and SGX remarks before parting of for two weeks

[Jarkko Sakkinen]

On Fri, Jul 12, 2019 at 01:12:23PM +1000, James Morris wrote:
> On Fri, 12 Jul 2019, Jarkko Sakkinen wrote:
> 
> > Before going to a two week vacation (sending v21 today), I'll make some
> > remarks on SGX and LSM's:
> > 
> > 1. Currently all patch sets proposing LSM changes are missing a problem
> >    statement and describe a solution to an undescribed problem.
> > 2. When speaking of SELinux I haven't seen any draft's on how would
> >    define a policy module with the new constructs. Does not have to
> >    be a full policy modules but more like snippets demosntrating that
> >    "this would work".
> > 3. All the SELinux discussion is centered on type based policies.
> >    Potentially one could isolate enclaves with some UBAC or RBAC
> >    based model. That could be good first step and might not even
> >    require LSM changes.
> 
> Unless I misunderstand what you mean here, RBAC and UBAC in SELinux still 
> require LSM hooks, and are typically integrated with Type Enforcement.

OK, I was thinking something like with normal DAC just to have SGID
for enclaves. Just learning basic SELinux concepts. Still quite alien
world to me.

/Jarkko