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 >> 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 >>>
Attachment:
signature.asc
Description: OpenPGP digital signature
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
