One of the things that we de-emphasized in the Fedora Releases of 
SELinux up til not is the RBAC support.  We
have basically made staff_r and user_r almost equivalent.  The reason we 
did this, is that we felt the system was
unmanagable for a normal administrators and would just result in SELinux 
getting a bad name and being turned off.
So for the first release of FC2 we turned off alot of the handling of 
roles.  Now that we have developed targeted policy
we are reviting some of the decisions we made around strict policy and 
working to make it "stricter".  

One problem I still have with RBAC though is the labeling of files based 
on the role of the user.  IE (staff_home_t versus
user_home_t).  I believe this causes many problems, without much benefit.

1.  Causes problems with sharing files between users,   IE a staff user 
coping a file to tmp and then the user
can't read it, because it has the wrong type. 
2.  Requirement that selinux-policy-strict-sources be installed and a 
rebuild of policy in order to change the roles of a user.
3.  But the number one problem I have is with relabeling files.  If I 
were to implement roles management in
system-config-securitylevel/adduser, I would need to trigger a relabel 
any time a role of a user was changed.  This
relabel would have to be inteligent enough to figure out not only the 
home directories, but also the files in /tmp and potentially
files in html files scattered over the system.  I find this an 
unworkable situation.

So yesterday I went though the policy and created a new tunable 
single_user_file_type, that causes the policy to share a common
filetypes between staff and users.  (Haven't completed this for http yet). 

With this tunable and the new SELinux Policy Modules.  I believe we can 
begin to implement a sane mechanism for handling roles
without causing the problems addressed above.

With SELinux Policy Modules, can I build an system-config-user/adduser 
that would modify a file under /etc/selinux/strict/roles/
(the users file) and then reload just that policy?

Comments????

Dan