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

["Serge E. Hallyn" <serge@hallyn.com>]

Quoting Casey Schaufler (casey@schaufler-ca.com):
> Serge E. Hallyn wrote:
...
> > Briefly, all security fields must be exported by the LSM as a simple
> > null-terminated string.  They are checkpointed through the
> > security_checkpoint_obj() helper, because we must pass it an extra
> > sectype field.  Splitting SECURITY_OBJ_SEC into one type per object
> > type would not work because, in Smack, one void* security is used for
> > all object types.
> 
> I do not understand why the Smack behavior is a limitation here.

Well it's not the Smack behavior, it's the combination of Smack's
and SELinux's behavior :)

In the end what I have here is probably best anyway - what is
stored in the object hash is not a security struct as known
by any LSM, but a generic object label.  So at
object_hash_types[CKPT_OBJ_SEC]->restore(), we don't re-create
an actual security struct, but just a string which is later
used by security_xyztype_restore() to create an actual label.

> >   But we must pass the sectype field because in
> > SELinux a different type of structure is stashed in each object type.
> 
> 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.

...

> > +	/* str will be alloc'ed for us by the LSM.  We will free it when
> > +	 * we clear out our hashtable */
> >   
> 
> Why do you think that you need a copy? Sure, SELinux always gives you
> a copy, but Smack keeps "contexts" around and making a copy is not only
> unnecessary, but wasteful. If you free the "context" with the appropriate
> call (security_release_secctx) you will get the "free allocated memory"
> behavior desired by SELinux and the "do nothing" behavior of Smack. For
> free, assuming that you also fix your Smack hook so that it works in the
> way Smack deems "Correct".

Hmm, that should be doable.  Mind you these are not the same as
secctx's returned by secid_to_secctx.  Though selinux_release_secctx 
is implemented as a simple kfree, so it would 'just work.'  I'm
not sure if it's better to just re-use it, or introduce a new
security_release_context() that does the same thing...

thanks,
-serge