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.
> 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
> > >
> > >
> > >
>