On Thu, 2013-10-10 at 15:47 +0200, Dominick Grift wrote: > 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. > > > > > > comments: > > sssd_read_public_files(iotop_t) needs to be wrapped in > optional_policy(`') since the sssd policy module, and functionality is > optional. we dont want this module to depends on the sssd module Done. > > You can remove the iotop_role(): its pretty useless. Do you mean this line? role iotop_roles types iotop_t; > > you will probably want to allow the iotop_t domain dac_override , since > it will probably often be run from a unpriv user home directory rather > than /root > > i am unclear as to why "files_read_etc_files(iotop_t)" is needed. does > it read /etc/nsswitch.conf? I thought it did, but I have removed the line and it worked with no denial. I think the trap I fell into was that I tried the application in permissive mode without a complete set of rules, then I received other denials as a result, to which I added rules I didn't need. > > allow iotop_t self:netlink_route_socket create_socket_perms; > allow iotop_t self:netlink_socket create_socket_perms; <-- duplicate > allow iotop_t self:netlink_socket rw_socket_perms; <-- duplicate > allow iotop_t self:unix_dgram_socket rw_socket_perms; > > i would probably used this instead: > > allow iotop_t self:netlink_route_socket r_netlink_socket_perms; > allow iotop_t self:netlink_socket create_socket_perms; > allow iotop_t self:unix_dgram_socket create_socket_perms; I have setup my policy to match this, but I think I'll need to read the differences in what those socket_perms options do before I understand it completely. I'll use the reference you previously gave. > o and i think you forgot to add dev_read_rand(iotop_t) It needed urandom, which is added (And it doesn't generate a denial, so I won't add it) Attached again. -- Sincerely, William Brown http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xEFC416D781A8099A
policy_module(iotop, 1.0.0)
########################################
#
# Declarations
#
attribute_role iotop_roles;
roleattribute system_r iotop_roles;
type iotop_t;
type iotop_exec_t;
application_domain(iotop_t, iotop_exec_t)
role iotop_roles types iotop_t;
#permissive iotop_t;
########################################
#
# iotop local policy
#
allow iotop_t self:capability net_admin;
allow iotop_t self:netlink_route_socket r_netlink_socket_perms;
allow iotop_t self:netlink_socket create_socket_perms;
allow iotop_t self:unix_dgram_socket create_socket_perms;
kernel_read_system_state(iotop_t)
dev_read_urand(iotop_t)
domain_getsched_all_domains(iotop_t)
domain_read_all_domains_state(iotop_t)
auth_read_passwd(iotop_t)
corecmd_exec_bin(iotop_t)
miscfiles_read_localization(iotop_t)
userdom_use_user_terminals(iotop_t)
optional_policy(`
sssd_read_public_files(iotop_t)
')
Attachment:
signature.asc
Description: This is a digitally signed message part
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
