On Wednesday, October 27, 2010 12:27:34 pm Dominick Grift wrote: > On Wed, Oct 27, 2010 at 11:26:55AM +0200, Roberto Sassu wrote: > > On Tuesday, October 26, 2010 10:19:40 pm Dominick Grift wrote: > > > On Tue, Oct 26, 2010 at 07:49:46PM +0200, Roberto Sassu wrote: > > > > On Monday, October 25, 2010 06:32:50 pm Dominick Grift wrote: > > > > > 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. > > > > > > > > > > > > > Ok, i will try. I suppose i have to modify the constraints file by adding for example in > > > > the 'basic_ubac_conditions' definition: > > > > or u1 = unconfined_u > > > > or u2 = unconfined_u > > > > > > I do not believe you would need to modify the contraints i think you would just call the interfaces in ubac.if and that you ubac exempt the caller. > > > > > > > This means that i need to call 'ubac_process_exempt' for each domain or 'ubac_file_exempt' for each file i want to exclude > > from ubac enforcement. This seems to me difficult to apply because the domain 'rpm_t' can create or relabel most of defined types and they will > > have in the security context the same user of the process. > > > > > > > > > > > > > > > Just another question: is it possible to duplicate the definition of a type in a simple manner? > > > > I need more than an alias, because if i do chcon -t <alias> the extended attribute is set to > > > > the original type. > > > > > > i am not sure that i understand what you mean but you could try the typealias statement. > > > > > > > Ok, i will explain this better. I want to have two selinux labels with different security identifier but with > > the same set of rules defined. > > I am afraid you have lost me. I suggest that we continue this conversation on refpolicy@xxxxxxxxxxxxxx, since repolicy maintainer PeBenito designed ubac and knows a heck of a lot more about it then i do. Unfortunately fedora does not support it. > > Hopefully PeBenito can shed some more light on the issue involved and possible solutions. Thanks for your help. Just to have the Fedora selinux policy working with UBAC, i've patched the file policy/user_constraints and this prevents the enforcement to be applied for users unconfined_u, sysadm_u , staff_u, root other than system_u. I have got a little problem when compiling the policy with the patch, because the gen_user statement for the user unconfined_u is missing in the file users-targeted. I have a question about the development of the Fedora selinux policy: i see there is a git repository and i think it may be useful creating some tags or branches in order to identify the policy shipped with stable versions of Fedora. > > > > > > > i am not sure if it matter to what type the xattr is set. they are both identical if you defined a typealias? > > > > > > > Yes, the original type and the alias are probably mapped to the same security identifier. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>>> 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 > > > > > > > > > > > > > > > > > > > -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
