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?).
>
user tty devices are labeled user_tty_device_t, and these are covered by
userdom_use_user_terminals()
console_device_t is for /dev/console
> 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.
>
Well not sure but if for example a system process runs iotop
non-interactively then there is no user terminal to use i guess, so it
*may, or may not* use unallocated terminals or console_device_t
if you cannot produce it then no need to add rules for it.
there's this simple guideline i suggest for policy writers: do not
assume.
>
> 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.
>
permissions sets are indeed for example the "create_socket_perms", they
are sets of permissions that are grouped into a single readable string.
They provide a single point of failure
for example:
to execute a executable file you need a set of permissions. these
permission are grouped identified with a human readable string:
define(`exec_file_perms',`{ getattr open read execute ioctl
execute_no_trans }')
Now if you use the exec_file_perms string, whenever you want to execute
a file. then you have a single point of failure in case something
changes in the future wrt the permission needed execute a file.
because you only have to edit the definition, and the change will
propagate.
the permission sets can be found here:
/usr/share/selinux/devel/include/support/obj_perm_sets.spt
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
