On Fri, 2013-10-11 at 00:28 +1030, 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. > Ok now it looks ok. Although i still suspect it needs dac_override capability ( it needed it when i used it ) sooner or later. but we will see. -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
