selinux policy UBAC question

[Roberto Sassu]

On Monday, October 25, 2010 06:00:42 pm Dominick Grift wrote:
> On 10/25/2010 05:47 PM, Dominick Grift wrote:
> > On Mon, Oct 25, 2010 at 05:06:05PM +0200, Roberto Sassu wrote:
> >> On Monday, October 25, 2010 04:27:22 pm Dominick Grift wrote:
> >>> On Mon, Oct 25, 2010 at 02:45:54PM +0200, Roberto Sassu wrote:
> >>>> Hi all
> >>>>
> >>>> i'm using the selinux policy shipped with Fedora 13 and UBAC turned on.
> >>>> I removed the unconfined package and i noted the unconfined_t domain with
> >>>> unconfined_u user is unable to access a file with another selinux user.
> >>>> I tried to build a custom module which contains the line:
> >>>>
> >>>> ubac_process_exempt(unconfined_t)
> >>>
> >>> like it says this only exempts the callers access to processes
> >>>
> >>> in the sysadm module this is added:
> >>>
> >>> ubac_process_exempt(sysadm_t)
> >>> ubac_file_exempt(sysadm_t)
> >>> ubac_fd_exempt(sysadm_t)
> >>>
> >>> That should pretty much exempt the caller.
> >>> Note though that ubac has issues, i am not sure how much issues in fedora but in normal refpolicy the *_admins do not work because you want to start services as system_u else unpriv users wont be ableto access resources. There is no way to change to system_u unless i guess you use runcon.
> >>
> >> I'm using the UBAC feature in order to identify the combination of user/program that is allowed to acces a specific label. UBAC permits to implement this access control model by
> >> using the policy for the user_t domain and assigning a selinux user to each user in the platform.
> >> My target is to have an usable system and it seems that the ubac is not yet ready to be used in desktop platforms.
> >> Another solution is to create different user domains by using the proper template. There are other alternatives in order to implement this access control model?
> > 
> > If i concerns apps started by users, then i think it may still be possible. Back in the day we used prefixes for process and files created by processes started by users. User home directories had a role prefix. now all users use the user_home(_dir)_t. But back then we had it prefixed like staff_home_t, users_home_t, someuser_home_t
> > 
> > that allowed use to seperate users and their resources. We used to implement these prefixes in the per role templates for user apps
> > 
> > like for example: allow staff_t staff_mozilla_t:file read_file_perms;
> > 
> > We still use per role templates but only to seperate processes, we no longer use it to seperate user home content.
> > 
> > The -P (prefix option) with semanage was used to define the prefix to be used for user home dirs
> > 
> > semanage user -a -L s0 -r s0-s0:c0.c1023 -R "staff_r sysadm_r" -P staff staff_u (i believe it was)
> > 
> > Not sure if this prefixing of user home dirs still works.
> > 
> 
> But regardles of whether the -P option in semanage still works, you will
> still be able to implement something using a per role template
> 
> Have a look at one, for example the one is sudo.if
> 
> you can just prefix the files created by your user applications. You may
> not be easily able to seperate anything else but its something.
> 
> example:
> 
> manage_files_pattern($1_myapp_t, $1_myapp_file_t, $1_myapp_file_t)
> userdom_user_home_dir_filetrans($1_myapp_t, $1_myapp_file_t, file)
> 
> HOME_DIR/\.myapp_file	--	gen_context(system_u:object_r:ROLE_myapp_file_t,s0)
> 
> Where $1 is a role prefix. That *might* work
> 

If i understand correctly i need to create first, for the user user1, the initial domain user1_t;
then i have to duplicate the ssh policy by creating the domain user1_ssh_t.
A relevant issue i find in this approach is that i need to modify the policy each time a new user
is created.
I think it should work but it is much more simple to have user1_u:user_r:user_t:s0 and
user1_u:user_r:ssh_t:s0 security contexts.
Just another question about the ubac, does it is possible to configure the policy to isolate user1_u
from user2_u, and to grant accesses from user1_u, user2_u to system_u, unconfined_u, staff_u and sysadm_u? 

> >> Thanks.
> >>
> >>>
> >>> That brings us to the second issue that is that you probably want to build policy with sysadm_direct_initrc option enabled. That way to can for example run rpm /yum in the rpm_t domain with system_u. Else it will install files with sysadm_u id and then ubac users cannot access it.
> >>>
> >>> Those two issues were enough reason for me to turn it of. (especially not being able to use the *_admins.
> >>>
> >>>
> >>>>
> >>>> but this does not solve the issue. How do i configure the policy to allow some
> >>>> domains to circumvent the UBAC enforcement?
> >>>> Thanks in advance for replies.
> >>>>
> >>>> Roberto Sassu
> >>>> --
> >>>> selinux mailing list
> >>>> selinux at lists.fedoraproject.org
> >>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
> >>>
> 
> 
>