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. > > alright, i guess i overlooked that one when reviewing your policy > > > > 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? You can see that by looking up the interfaces. but console devices have type console_device_t, where user terminals are prefixed with "user" (back in the role separation days these would be prefixed per role (sysadm_devpts_t, staff_devpts_t, user_devpts_t etc) > > 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. > OK, makes sense > > 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; auth_read_passwd_file() (or something like that) > allow iotop_t random_device_t:chr_file read; dev_read_rand() > > #!!!! 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. > OK but allowing these isnt such a bad deal and it gets rid of the avc denials. one should be very conservative with dontaudit keyword TE AV rules > I would appreciate if you could review this policy. Thanks again for > your help. > policy review: kernel_rw_unix_dgram_sockets(iotop_t) This one makes no sense, please look up the interface and try to determine why it doesnt make sense for iotop You should use permission sets for the "self" rules to provide a single point of failure ( see my video ) Other than that looks good (except that you dont need to define the iotop_role()) -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
