On Wed, 2013-10-09 at 09:41 +0200, Dominick Grift wrote:
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
This is the only one that's missing. The rest are all correct as your examples show.
Solved, by adding:
role iotop_roles types iotop_t;
to my te file.
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
What is the difference between userdom_use_user_terminals and term_use_console? I assume that since the latter is in the kernel section, it's related to actually terminals ie ttys?
As per the net_admin capability, removing it iotop gives this friendly spiel: Netlink error: Operation not permitted (1)
The Linux kernel interfaces that iotop relies on now require root priviliges or the NET_ADMIN capability. This change occured because a security issue (CVE-2011-2494) was found that allows leakage of sensitive data across user boundaries. If you require the ability to run iotop as a non-root user, please configure sudo to allow you to run iotop as root.
Please do not file bugs on iotop about this.
I have attached my version of the policy.
It still receives a small number of denials, that audit2allow lists here:
#============= iotop_t ============== allow iotop_t passwd_file_t:file read; allow iotop_t random_device_t:chr_file read;
#!!!! This avc can be allowed using the boolean 'global_ssp' allow iotop_t urandom_device_t:chr_file read;
But these don't prevent iotop working.
I would appreciate if you could review this policy. Thanks again for your help.