On Fri, 2011-03-04 at 10:38 +0000, HarryCiao wrote: > Hi Stephen and Chris, > > I would like to dig deeper on this topic and I have started thinking > below questions as a starting point, it definitively would help me to > get warmed up quickly if you could help pointing me at the background > story :-) > > [cut] > > > ... Maybe we can come up with some generalized > > > solution that will be more flexible going forward for configuring > how > > > different parts of the context are assigned for different classes. > We > > > have talked previously about using the role field even for files > rather > > > than just making them all object_r. > > > > 1. Would it work simply to make the newly created objects have the > role of "scontext->role" than "object_r" in security_compute_sid? No, that would break existing policies. We need a way to allow existing systems to still use object_r while allowing future policies to leverage new support for using the role field in object security contexts. I sketched one possible approach in the earlier thread that Chris referenced, i.e. inherit from tcontext->role (parent directory) and add role transition support on object classes. Then on existing systems where directories are labeled object_r, everything will still work as before, but with new policies, we can set up role transitions on the file classes to use the subject role where that is desired. > 2. If files' role is not "object_r" anymore, what changes in refpolicy > and SELinux kernel space would have to be done accordingly? In the kernel, we check for OBJECT_R_VAL and exempt security contexts with that role from the validation checks on user-role, role-type, and user-range. So using subject roles on objects will enable that checking and require that the policy explicitly authorize those pairings. > ! 3. Where can I find our previously talks on such topic? Looks like Chris did a good job of hunting down the prior discussions. -- Stephen Smalley National Security Agency -- 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.
