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@xxxxxxxxxxxxxxxxxxxxxxx > >>>> https://admin.fedoraproject.org/mailman/listinfo/selinux > >>> > > > -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
