Re: iotop policy development advice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
> 
> 

o and i think you forgot to add dev_read_rand(iotop_t)

--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux





[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux