On Thu, 2013-10-10 at 23:32 +1030, William Brown wrote: > On Thu, 2013-10-10 at 10:09 +0200, Dominick Grift wrote: > > On Thu, 2013-10-10 at 10:08 +1030, William Brown wrote: > > > 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 might want to give access to both console_device_t as well as user > > terminals if it wants to use console_device_t in your test scenario > > > > this app can also be run non interactively in scripts so it might in > > that case need to be able to rw console devices > > > > generally though this app gets executed from user pseudo terminals by > > users ( for example from xterm, or gnome terminal or a ssh shell and so > > in that case you need to allow it to use user terminals) > > > > have a look in /dev/ to see how the different terminals are labeled > > > > I couldn't find anything in the documentation relating to > console_device_t. I tried iotop from a tty, and that worked correctly > (not sure if this was meant to be the case?). > > What would be the difference to the application if it were run from a > script (ie iotop -b). I couldn't generate any denials with my current > policy trying this .... Some more detail about the different console > types (or links) would be great. > > > Regarding the other points: > > Added the extra rules as you suggested to remove the avc's that were > generated. > > I removed kernel_rw_unix_dgram_sockets(iotop_t) and tested, finding that > I didn't need it. This is likely my mistake as I saw the dgram denial, > and in my research found this and added it. I guess this is a lesson in > adding one or two lines at a time and testing. > > I have improved the interface file, adding (hopefully) better > explanations. > > Fixed the ordering of the interface calls. > > > You should use permission sets for the "self" rules to provide a > > single > > point of failure ( see my video ) > > I remember you doing something different with the self rules, but I > don't understand what you mean by permission sets. As far as I remember, > you left them just as "self" rules? Is this the "create_socket_perms" > that you use? If this is the case, is there a location where these are > documented / source code to these for reference? I have added some of > these, and the policy works, but I would still appreciate your advice. > > comments: sssd_read_public_files(iotop_t) needs to be wrapped in optional_policy(`') since the sssd policy module, and functionality is optional. we dont want this module to depends on the sssd module You can remove the iotop_role(): its pretty useless. you will probably want to allow the iotop_t domain dac_override , since it will probably often be run from a unpriv user home directory rather than /root i am unclear as to why "files_read_etc_files(iotop_t)" is needed. does it read /etc/nsswitch.conf? allow iotop_t self:netlink_route_socket create_socket_perms; allow iotop_t self:netlink_socket create_socket_perms; <-- duplicate allow iotop_t self:netlink_socket rw_socket_perms; <-- duplicate allow iotop_t self:unix_dgram_socket rw_socket_perms; i would probably used this instead: allow iotop_t self:netlink_route_socket r_netlink_socket_perms; allow iotop_t self:netlink_socket create_socket_perms; allow iotop_t self:unix_dgram_socket create_socket_perms; -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
