iotop policy development advice

[Dominick Grift]

On Tue, 2013-10-08 at 14:28 +0200, Dominick Grift wrote:
> 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
> 

I made a 30 minute demonstration about creating policy for iotop (on
rhel6) : https://www.youtube.com/watch?v=WcF9QkqLcKs

> > > 
> > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=10163
> > > 
> > > 
> > > --
> > > selinux mailing list
> > > selinux at lists.fedoraproject.org
> > > https://admin.fedoraproject.org/mailman/listinfo/selinux
> > 
> > 
> 
>