iotop policy development advice

[Dominick Grift]

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.