On Thu, 2013-10-10 at 10:28 -0400, Daniel J Walsh wrote: > 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. yes, but It doesnt need any authentication though, and also many other hallmarks of nsswitch are not there for example reading network config or do dns resolving, or creating tcp/udp sockets not sure why it needs to create netlink route sockets ( i am assuming that in some scenario it might need to read the routing table, but against my own advise i made assumptions this actually a really simple app, the only thing that i wonder about are the details about the net_admin and netlink_route_socket. I thought it might have been for iscsi scenarios but thats just assumption -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
