Serge E. Hallyn wrote: > Quoting Casey Schaufler (casey@xxxxxxxxxxxxxxxx): > >> Serge E. Hallyn wrote: >> >>> Quoting Casey Schaufler (casey@xxxxxxxxxxxxxxxx): >>> >>>> 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. >>> ... >>> >>> >>> >>>>> + /* 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. >>> >> Now why is that? If they are different things, what are they? >> >> What is the difference between a secctx and a context? >> I got a bit confused because the word "context" has been >> used to refer to the thing represented by a secctx for a >> long time. >> > > I know, I know, I should come up with a better name. But while > an selinux context would be > > root_u:root_r:root_t > > the blob I have to checkpoint for a task would perhaps be > > root_u:root_r:root_t:::null:::null::null:::user_u:serge_r:serge_t:::null > What you really want is a textual representation of the security blob if I read this correctly. Seems like you could call this either a "blob string" or a "context collection" or a "checkpoint string". -- 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.
