From: harrytaurus2002@hotmail.com (HarryCiao) Date: Fri, 4 Mar 2011 10:38:33 +0000 Subject: [refpolicy] Further questions about configuring contexts differently for variant classes In-Reply-To: <4D667EBA.3060205@tresys.com> References: <1298554512.31953.38.camel@moss-pluto>,<4D667EBA.3060205@tresys.com> Message-ID: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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? 2. If files' role is not "object_r" anymore, what changes in refpolicy and SELinux kernel space would have to be done accordingly? 3. Where can I find our previously talks on such topic? > It certainly would be nice to have all objects get the role of their > creator so we can bring role-based policy separations back using RBAC > features and not rely on 1:1 user:role mapping + UBAC. 4. It seems that we used to have RBAC, then why we have to have dropped it? 5. Does the "1:1 user:role mapping" mean the mapping from linux user to selinux user, and the mapping from selinux user to the roles that he/she could assume? 6. Any discussion email thread about how UBAC works and why we would want "1:1 user:role mapping + UBAC"? I know I've asked a lot of silly questions, thanks a lot for your time and patience! Best regards, Harry -------------- next part -------------- An HTML attachment was scrubbed... URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110304/78a5c31f/attachment.html