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. -- Sincerely, William Brown http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xEFC416D781A8099A
## <summary>Simple top-like I/O monitor</summary>
########################################
## <summary>
## Allow execution of iotop in the iotop domain from the target domain.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed to transition to iotop.
## </summary>
## </param>
#
interface(`iotop_domtrans',`
gen_require(`
type iotop_t, iotop_exec_t;
')
corecmd_search_bin($1)
domtrans_pattern($1, iotop_exec_t, iotop_t)
')
########################################
## <summary>
## Execute iotop in the iotop domain, and
## allow the specified role to access the iotop domain.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed to transition
## </summary>
## </param>
## <param name="role">
## <summary>
## The role to be allowed into the iotop domain.
## </summary>
## </param>
#
interface(`iotop_run',`
gen_require(`
type iotop_t;
attribute_role iotop_roles;
')
iotop_domtrans($1)
roleattribute $2 iotop_roles;
')
########################################
## <summary>
## Role allowed to access and manage processes in the iotop domain.
## </summary>
## <param name="role">
## <summary>
## Role allowed access to iotop
## </summary>
## </param>
## <param name="domain">
## <summary>
## User domain for the role
## </summary>
## </param>
#
interface(`iotop_role',`
gen_require(`
type iotop_t;
attribute_role iotop_roles;
')
roleattribute $1 iotop_roles;
iotop_domtrans($2)
ps_process_pattern($2, iotop_t)
allow $2 iotop_t:process { signull signal sigkill };
')
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 create_socket_perms; allow iotop_t self:netlink_socket create_socket_perms; allow iotop_t self:netlink_socket rw_socket_perms; allow iotop_t self:unix_dgram_socket rw_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) files_read_etc_files(iotop_t) miscfiles_read_localization(iotop_t) userdom_use_user_terminals(iotop_t) 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
