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.