[refpolicy] Further questions about configuring contexts differently for variant classes
harrytaurus2002 at hotmail.com
Fri Mar 4 04:38:33 CST 2011
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 :-)
> > ... 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!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the refpolicy