On Wed, 2013-10-09 at 09:41 +0200, Dominick Grift wrote: > On Wed, 2013-10-09 at 08:04 +1030, William Brown wrote: > > > > > > > > > I made a 30 minute demonstration about creating policy for iotop (on > > > > > rhel6) : https://www.youtube.com/watch?v=WcF9QkqLcKs > > > > > > > > > > > > > Fantastic. Thanks for your combined emails. It has revealed a lot to me. > > > > I'll watch your video, and will create a similar policy for iotop on > > > > Fedora. If you don't mind, I'll post it here for review once I'm done. > > > > > > > > > > sure, you can post it but if the policy looks like the one i created in > > > my video then its ok > > > > > > > Well hopefully it does. I'm not aiming to copy your policy directly, as > > I want to learn the steps so I can write these for myself. > > > > I have already run into one issue. I have created an iotop module and > > iotop_sysadm module, but once loaded I see a number of errors in > > ausearch like: > > > > libsepol.sepol_context_to_sid: could not convert > > staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 to sid > > libsepol.context_from_record: invalid security context: > > "staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023" > > libsepol.context_from_record: could not create context structure > > libsepol.context_from_string: could not create context structure > > > > > > It says that the staff_u:sysadm_r:iotop_t:s0-s0:c0.c1023 content is > invalid. So you should check whether the combination of these security > identifiers is valid > > you can use the seinfo , semanage and sesearch tools to determine that > > to determine whether your uid/gid is associated to > staff_u/s0-s0:c0.c1023: > > semanage login -l |grep myadm > myadm staff_u s0-s0:c0.c1023 > > to determine whether the staff_u sid is associated to the sysadm_r role > and range of s0-s0:c0.c1023: > > semanage user -l | grep staff_u > staff_u user s0 s0-s0:c0.c1023 > staff_r sysadm_r system_r unconfined_r > > to determine whether staff_r can manually change to sysadm_r: > > sesearch --role_allow | grep "allow staff_r " | grep sysadm_r > allow staff_r sysadm_r; > > to determine whether the sysadm_r role is associated to the iotop_t > domain: > > seinfo -xrsysadm_r | grep iotop > iotop_t > This is the only one that's missing. The rest are all correct as your examples show. Solved, by adding: role iotop_roles types iotop_t; to my te file. > > to determine whether whether sysadm_t automatically domain transitions > to iotop_t when he runs a file with type iotop_exec_t: > > sesearch -ASCT -s sysadm_t -t iotop_exec_t | grep type_transition > type_transition sysadm_t iotop_exec_t : process iotop_t; > > if all the above prerequisites are met then things should probably work > in the default fedora/rhel set up 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? As per the net_admin capability, removing it iotop gives this friendly spiel: Netlink error: Operation not permitted (1) The Linux kernel interfaces that iotop relies on now require root priviliges or the NET_ADMIN capability. This change occured because a security issue (CVE-2011-2494) was found that allows leakage of sensitive data across user boundaries. If you require the ability to run iotop as a non-root user, please configure sudo to allow you to run iotop as root. Please do not file bugs on iotop about this. I have attached my version of the policy. It still receives a small number of denials, that audit2allow lists here: #============= iotop_t ============== allow iotop_t passwd_file_t:file read; allow iotop_t random_device_t:chr_file read; #!!!! This avc can be allowed using the boolean 'global_ssp' allow iotop_t urandom_device_t:chr_file read; But these don't prevent iotop working. I would appreciate if you could review this policy. Thanks again for your help. -- Sincerely, William Brown http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xEFC416D781A8099A
/usr/sbin/iotop -- gen_context(system_u:object_r:iotop_exec_t,s0)
## <summary>Simple top-like I/O monitor</summary>
########################################
## <summary>
## Execute TEMPLATE in the iotop domin.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed to transition.
## </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 the iotop domain.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed to transition
## </summary>
## </param>
## <param name="role">
## <summary>
## The role to be allowed 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 access for iotop
## </summary>
## <param name="role">
## <summary>
## Role allowed access
## </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 { bind create };
allow iotop_t self:netlink_socket { bind create setopt getattr read write };
### Why is this unix_dgram_socket create not covered by the kernel_rw_unix_dgram_sockets interface?
allow iotop_t self:unix_dgram_socket { connect create write };
corecmd_exec_bin(iotop_t)
miscfiles_read_localization(iotop_t)
files_read_etc_files(iotop_t)
domain_getsched_all_domains(iotop_t)
domain_read_all_domains_state(iotop_t)
kernel_read_system_state(iotop_t)
kernel_rw_unix_dgram_sockets(iotop_t)
userdom_use_user_terminals(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
