iotop policy development advice

[Dominick Grift]

On Wed, 2013-10-09 at 08:04 +1030, William Brown wrote:
> > > 
> > > > I made a 30 minute demonstration about creating policy for iotop (on
> > > > rhel6) : https://www.youtube.com/watch?v=WcF9QkqLcKs
> > > > 
> > > 
> > > Fantastic. Thanks for your combined emails. It has revealed a lot to me.
> > > I'll watch your video, and will create a similar policy for iotop on
> > > Fedora. If you don't mind, I'll post it here for review once I'm done.
> > > 
> > 
> > sure, you can post it but if the policy looks like the one i created in
> > my video then its ok
> > 
> 
> Well hopefully it does. I'm not aiming to copy your policy directly, as
> I want to learn the steps so I can write these for myself.
> 
> I have already run into one issue. I have created an iotop module and
> iotop_sysadm module, but once loaded I see a number of errors in
> ausearch like:
> 
> libsepol.sepol_context_to_sid: could not convert
> staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 to sid
> libsepol.context_from_record: invalid security context:
> "staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023"
> libsepol.context_from_record: could not create context structure
> libsepol.context_from_string: could not create context structure
> 
> 

It says that the staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 content is
invalid. So you should check whether the combination of these security
identifiers is valid

you can use the seinfo , semanage and sesearch tools to determine that

to determine whether your uid/gid is associated to
staff_u/s0-s0:c0.c1023:

semanage login -l |grep myadm
myadm                     staff_u                   s0-s0:c0.c1023

to determine whether the staff_u sid is associated to the sysadm_r role
and range of s0-s0:c0.c1023:

semanage user -l | grep staff_u
staff_u         user       s0         s0-s0:c0.c1023
staff_r sysadm_r system_r unconfined_r

to determine whether staff_r can manually change to sysadm_r:

sesearch --role_allow | grep "allow staff_r " | grep sysadm_r
   allow staff_r sysadm_r;

to determine whether the sysadm_r role is associated to the iotop_t
domain:

seinfo -xrsysadm_r | grep iotop
         iotop_t


to determine whether whether sysadm_t automatically domain transitions
to iotop_t when he runs a file with type iotop_exec_t:

sesearch -ASCT -s sysadm_t -t iotop_exec_t | grep type_transition
   type_transition sysadm_t iotop_exec_t : process iotop_t;

if all the above prerequisites are met then things should probably work
in the default fedora/rhel set up

> My research shows this is when you forget the "s0" on a file context,
> but this isn't the case here. 
> 
> I've attached my policy that I have partially written at this point, and
> any advice would be appreciated on this.
> 
>