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(a)oss.tresys.com, 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(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
> > > >
> > > >
> > > >
> >