Re: Single home directory type for all roles.

[Daniel J Walsh <dwalsh@redhat.com>]

Colin Walters wrote:

>On Thu, 2004-12-09 at 11:50 -0500, Daniel J Walsh wrote:
>
>  
>
>>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. 
>>    
>>
>
>I feel that what we really need is an explicit file sharing area; for
>example the gnome-user-share program uses /home/$USER/Public.  Having a
>special label for public files like this will also allow us to write
>policy for the gnome-user-share Apache daemon.  It does seem wrong to me
>for any user_t to have access to my staff_t temporary files, and also
>the other way around (remember that user_t/staff_t prevents /tmp race
>conditions).  I run a strict server on which I have several users who I
>don't *entirely* trust.  The extra assurance the user_t/staff_t
>distinction brings is nice.
>
>  
>
Currently few people use staff, because user can do everything staff can 
do so you are not protected by this protection.
You also do not protect yourself from staff users attacking other staff 
users.

>>2.  Requirement that selinux-policy-strict-sources be installed and a 
>>rebuild of policy in order to change the roles of a user.
>>    
>>
>
>I'm not sure I see what's so bad about this.  I would assume that most
>people running strict will have to customize policy anyways.
>  
>
My goal is to get more people using strict, not just the ones capable of 
writing policy.

>  
>
>>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.
>>    
>>
>
>Hmm.  But the fact that in the default strict policy user_r and staff_r
>are nearly equivalent in terms of functionality is really a special
>case, no?  I imagine most people really using RBAC will be defining
>specialized roles such as webmaster_r, nurse_r, developer_r, etc.  In
>this situation it seems to me that it would be unusual for a person to
>switch roles entirely; much more likely they would gain a role.  And if
>they *did* switch roles, it seems likely that they would not have access
>to their old files at all.  
>
>  
>
If we move to this plan, we would turn off the compatability between 
user and staff.
So only staff users could su, usermod, newrole.  The reason they are the 
same now is because
of the labeling problem, and the inability to easily change from a user 
to a staff role.  Why would
you not have access to your old files, if you switch roles.  I agree 
this might be good in some cases
but can't we develop a less stringent rule that does not require relabeling.

>>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). 
>>    
>>
>
>I'm not saying it's not useful to have an option, but before
>recommending this, I'd like to think a bit more about any other possible
>solutions.  I don't have any good ideas about how to handle user_r ->
>staff_r in general right now though.
>
>  
>
>>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?
>>    
>>
>
>I haven't looked in detail at binary policy modules, but my guess is
>that they can't *delete* a role, type, or permission.  So it seems
>difficult to use a binary policy module to change a user's role, e.g.
>from user_r to staff_r as you suggest.
>
>
>  
>


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.