> >
> > 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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
