>
> 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
Okay. I saw the tty and pty device labelling. I am personally not fully
aware of the function of /dev/console and how it works on a linux
system, so I think I'll dodge this for now.
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.
I didn't add the rules. That is sound advice that I will follow.
> > 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
Thanks, I'll take a look. It's mainly so that when I say "Hmm what would
give me socket permissions" I can grep somewhere to find what "might" be
the answer. I do certainly agree that appears to be the right way to
reference such permissions.
I look forwards to your remaining comments of this policy.
--
Sincerely,
William Brown
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xEFC416D781A8099A