-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/10/2013 09:58 AM, William Brown wrote: > On Thu, 2013-10-10 at 15:47 +0200, Dominick Grift wrote: >> 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 > > Done. > >> >> You can remove the iotop_role(): its pretty useless. > > Do you mean this line? > > role iotop_roles types iotop_t; > > > >> >> 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? > > I thought it did, but I have removed the line and it worked with no denial. > I think the trap I fell into was that I tried the application in permissive > mode without a complete set of rules, then I received other denials as a > result, to which I added rules I didn't need. > >> >> 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; > > I have setup my policy to match this, but I think I'll need to read the > differences in what those socket_perms options do before I understand it > completely. I'll use the reference you previously gave. > >> o and i think you forgot to add dev_read_rand(iotop_t) > > It needed urandom, which is added (And it doesn't generate a denial, so I > won't add it) > > Attached again. > > > > -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/selinux > Me thinks you need auth_use_nsswitch() Looks like your code is calling getpw() Which is causing some of these access. auth_use_nsswitch will make you handle all forms of authorization. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJWuakACgkQrlYvE4MpobOhKgCeKmUJR0PNKStjQD7yHi9oQm2m wHQAoOEdMSBBipTDF4Wu+o0FJn+MxNqS =GVpR -----END PGP SIGNATURE----- -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
