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)
')
>
> [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
