[refpolicy] Further questions about configuring contexts differently for variant classes

[HarryCiao]

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