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@lists.fedoraproject.org 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