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.