On Thu, 2013-10-10 at 10:08 +1030, William Brown wrote: > 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. > Also give the interface file some love: ## Execute TEMPLATE in the iotop domin. This is that sepolicy script not replacing TEMPLATE with iotop ## The role to be allowed the iotop domain. "Role allowed access" Keep descriptions uniform and consistent These are API's, give them love, This is how others see your policy. (they will use your API's if they need to interact with or operate on iotop and iotop objects) Try to leave a good impression -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
