Quoting Casey Schaufler (casey@xxxxxxxxxxxxxxxx): > 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 -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
