On Tue, 2013-10-08 at 14:13 +0200, Dominick Grift wrote:
> On Tue, 2013-10-08 at 20:30 +1030, William Brown wrote:
> > Hi,
> >
> > I recently raised a bug[1] that while using confined users / system
> > administrators iotop would not work. Normally, iotop only runs as root,
> > so reasonably, it shouldn't run as staff_t, but it should be able to run
> > while in sysadm_t.
> >
> > Initially I have created the template with:
> >
> > sepolicy generate --application /usr/sbin/iotop
> >
> > I have build and installed this basic template for now, and of course as
> > predicted I'm still having some issues with denials.
> >
> > Am I on the right track to setup iotop with a iotop_t policy so that it
> > can access the kernel resources it needs when a user with sysadm_t calls
> > it? Given the messages I am seeing now are as follows:
> >
> > type=AVC msg=audit(1381226118.448:6322): avc: denied { create } for
> > pid=19326 comm="iotop" scontext=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023
> > tcontext=staff_u:sysadm_r:sysadm_t:s0-s0:c0.c1023 tclass=netlink_socket
> >
> > I assume that sysadm_t is not allowed to transition to iotop_t. What is
> > the right way to write this into my te file? I note that in the selinux
> > reference policy there are a number of calls to:
> >
> > optional_policy(`
> > uml_role(sysadm_r, sysadm_t)
> > ')
> >
> > What is the function of the <domain>_role() call, and is this what I
> > should be using (I have iotop_role in my if)
> >
> > Following that, what is the correct way to allow the sysadm_t to execute
> > this, but not staff_t etc?
> >
>
> The role templates are a bit of relic of the passed. They are templates
> that provide templated rules that allow the caller to run the program in
> the programs domain, and allow the callers role access to the programs
> domain.
>
> Back in the day, we used to prefix home directories for separation using
> role prefixes. So instead of user_home_t for generic user home content
> you would have sysadm_home_t for generic home content of sysadm.
>
> That concept was later dropped in favor of new security model called
> user based access control.
>
> Anyways nowadays the role template are generally used when the to
> transition program domain creates content in the user home directory or
> if the program needs to be able to run generic shells/binaries in the
> calling user domain.
>
> For iotop you could probably just create a iotop_run interface which
> takes care of the domain transition only and will allow the calling role
> access to the target domain. I do not believe iotop creates content in
> the user home directory, or that it runs shell, and other generic
> binaries on behalf of the calling process.
>
> An example of how your iotop module might look like is the dmidecode
> module, and its call by sysadm:
>
> optional_policy(`
> dmidecode_run(sysadm_t, sysadm_r)
> ')
>
>
Well the explanation above is not quite accurate.
there are more factors ( such are long running process might be suitable
for role interfaces ), plus i there is a difference between role
interfaces and per role templates.
But iptop can probably be considered a short running process, so think a
a run interface is probably the best option
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=10163
> >
> >
> > --
> > selinux mailing list
> > selinux@xxxxxxxxxxxxxxxxxxxxxxx
> > https://admin.fedoraproject.org/mailman/listinfo/selinux
>
>
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
