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