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
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.
>
>>>> 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(a)lists.fedoraproject.org
>>>>>>
https://admin.fedoraproject.org/mailman/listinfo/selinux
>>>>>
>>
>>
>>
> --
> selinux mailing list
> selinux(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/selinux