Stephen Smalley wrote: > On Sun, 2009-08-30 at 12:03 -0700, Casey Schaufler wrote: > >> 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. >> > > 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)? > Smack does support associating labels with incoming and/or outgoing packets from a particular socket. I haven't looked carefully at how the checkpoint/restart scheme is handling sockets in general, so I couldn't say if its going to get the rest of it right, either. In any case, that's something that is strictly in the realm of privileged processes for which checkpoint/restart is going to be one hairy potato. Processes that use this mechanism will be quite rare. The Smack port multiplexer (smackpolyport) that I'll be talking about in Portland and a small set of security enforcing applications should be about it. -- 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.
