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.