|
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 |
