On 10/25/2010 06:19 PM, Roberto Sassu wrote: > 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 do think the ssh.if module file has interfaces that can be used. not sure if those work. > 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? Yes i think that is possible. I was just thinking about what i said in my previous reply and it occurred to me that if sysadm is ubac exempt that i think in that case all identities can interac with ubac aswell. So if you make unconfined_u and staff_u ubac exempt, then i think those two users can access all ubac constrained objects/subjects, BUT also that ubac constrained subject can interact with the ubac excempt identities. So in that case my previous issue with ubac no longer stand. Because 1. if unconfined_u is ubac exempt and it runs rpm to install a package. then even though the files installed with have unconfined_u prefix, everyone can still interact with the files since unconfined_u is exempt 2 same for the *_admins: if staff_u is ubac exempt and he sudos to for example the webadm_t and restarts the web server, then the webserver will run with the staff_u identity, objects created by the webserver will have the staff_u identity, But that does not matter because even ubac constrained process can interact with ubac exempt process and objects. I think we should just try it out. I think it should indeed work out nicely. > >>>> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
