[Devel] Re: [PATCH 3/5] cr: add generic LSM c/r support

[Stephen Smalley]

On Sun, 2009-08-30 at 12:03 -0700, Casey Schaufler wrote:
> Serge E. Hallyn wrote:
> > Quoting Casey Schaufler (casey at schaufler-ca.com):
> >   
> >> Serge E. Hallyn wrote:
> >>     
> >>> Quoting Casey Schaufler (casey at schaufler-ca.com):
> >>>       
> >>>> But each can be expressed as a context, can't it?
> >>>>     
> >>>>         
> >>> A set of contexts (root_u:root_r:root_t:::system_u:system_r\
> >>> :system_t::...).
> >>>
> >>> There would be a problem if it were stored as a more
> >>> structured type, and if the ->restore handler wanted to
> >>> re-create an actual task_security_struct, ipc_security_struct,
> >>> etc.  So the last paragraph in the patch intro was just trying to
> >>> explain why the intermediate layer, storing a generic string on
> >>> the c/r object hash, needs to be there.  The thing that is
> >>> not possible is to place the actual void *security or a struct
> >>> task_security_struct on the objhash.
> >>>   
> >>>       
> >> Right. Now why do you need a set of contexts?
> >>     
> >
> > Because for SELinux, for instance, when checkpointing a security
> > context for a task, we want to checkpoint the actual context,
> > the fscreate context, the sockcreate context, keycreate context,
> > and the task create (exec_create) context.
> >   
> 
> My. That is quite a lot of contexts to keep track of.

Doesn't Smack also have at least one case where it supports multiple
distinct contexts for different purposes on a single object (e.g.
sockets)?

-- 
Stephen Smalley
National Security Agency

_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers