From: dac.override@gmail.com (Dominick Grift) Date: Wed, 27 Apr 2016 19:42:44 +0200 Subject: [refpolicy] [Patch V2 1/1] Add hwloc-dump-hwdata SELinux policy In-Reply-To: <5720F7FE.80603@tresys.com> References: <1461745535-6857-1-git-send-email-grzegorz.andrejczuk@intel.com> <1461770515-13153-1-git-send-email-grzegorz.andrejczuk@intel.com> <1461770515-13153-2-git-send-email-grzegorz.andrejczuk@intel.com> <5720F7FE.80603@tresys.com> Message-ID: <78d8575f-2650-81c7-1be1-176108885041@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/27/2016 07:33 PM, Christopher J. PeBenito wrote: > On 4/27/2016 11:21 AM, gandrejc wrote: > >> --- /dev/null +++ b/hwloc.if @@ -0,0 +1,103 @@ +## Dump >> topology and locality information from hardware >> tables. + +######################################## +## >> +## Execute hwloc dhwd in the hwloc dhwd domain. +## >> +## +## +## Domain >> allowed to transition. +## +## +# >> +interface(`hwloc_domtrans_hwloc_dhwd',` > > I would name this hwloc_domtrans_dhwd. fair enough > > >> +######################################## +## +## >> Manage hwloc runtime. +## +## >> +## +## Domain allowed access. +## +## >> +# +interface(`hwloc_manage_runtime',` + gen_require(` + >> type hwloc_var_run_t; + ') + + files_rw_pid_dirs($1) + allow $1 >> hwloc_var_run_t:dir manage_dir_perms; + allow $1 >> hwloc_var_run_t:file manage_file_perms; + allow $1 >> hwloc_var_run_t:lnk_file manage_lnk_file_perms; +') > > Are there subdirectories under /var/run/hwloc? If not, I would > reduce the access to rw_dir_perms on hwloc_var_run_t dirs. > Not that i am aware of but I would keep it atleast a little flexible. That is also why i added the lnk_file permissions. > Additionally, since the tool itself seems to create the top level > dir (based on the below filetrans in the .te), it doesn't seem > appropriate for this interface allow the caller > files_rw_pid_dirs(), but to simply search pid dirs. The > rw_pid_dirs would more likely fall under a filetrans interface. > By default the app probably creates /var/run/hwloc. However In my view callers of the interface should be able to create /var/run/hwloc as well with a manual type transition with mkdir -Z /var/run/hwloc if that is ever needed for whatever reason. If the hwloc_manage_runtime() is used together with files_pid_filetrans($1, hwloc_var_run_t, dir) then the compiler will remove the duplicate files_rw_pid_dirs() However if hwloc_manage_runtime() is used without files_pid_file_trans() then the caller can create /var/run/hwloc with a manual type transition (provided that he has access to setfscreatecon and compute_create (which nowadays is used by policycoreutils) So yes this is definitely a matter of taste. I like to keep some room to manouver and this this is a reasonable compromise. Eventually it is your call though, but if it was my call i would accept this as is obviously > >> diff --git a/hwloc.te b/hwloc.te new file mode 100644 index >> 0000000..3465e3a --- /dev/null +++ b/hwloc.te @@ -0,0 +1,28 @@ >> +policy_module(hwloc, 1.0.0) + >> +######################################## +# +# Declarations +# >> + +attribute_role hwloc_dhwd_roles; +roleattribute system_r >> hwloc_dhwd_roles; + +type hwloc_dhwd_t; +type hwloc_dhwd_exec_t; >> +init_system_domain(hwloc_dhwd_t, hwloc_dhwd_exec_t) +role >> hwloc_dhwd_roles types hwloc_dhwd_t; + +type hwloc_var_run_t; >> +files_pid_file(hwloc_var_run_t) + >> +######################################## +# +# Local policy +# >> + +allow hwloc_dhwd_t hwloc_var_run_t:dir manage_dir_perms; >> +allow hwloc_dhwd_t hwloc_var_run_t:file manage_file_perms; >> +files_pid_filetrans(hwloc_dhwd_t, hwloc_var_run_t, dir) + >> +dev_read_sysfs(hwloc_dhwd_t) >> > > - -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJXIPoQAAoJECV0jlU3+UdpvI8L/21oI/n/FRQR43HWUQtQBzjr 3lCgCRw619Zs/x7YbLSLwfqpFl8bWsFTJSDe+738fXNh+fmO9ktC+mQ3dyUYcDJJ uFkTkK4lvVmuF5kPd3/BI6xDKsPn849/gjEBOsRNnh9h16PqnGOdQJayWzr4aBIZ De0kFmLlLwocFxNllSoan060vdvG62tPNZuPlVtw1vgfA3isk9nDSMScajlEoK7k QN8TYP+PdJehLpHUyxZeQcxO1Bom6gFLSFcmHPRvimpTwiSVFzLYxKcuALQSbY9c N2YHXKSNgYVM959oILI8m2ufdqswSHW7sJ8Tl+1dQGoyewUxy92bKCukwFZFfy4K 4tVDKGWINJo5J7d2iromIBZKTVRuf3iMTgi6Jg0QCeU1QDTDLqzmQLEe+Ln7PN0U 55RnKrMrAFEy6pCJ9fY/F9NqhcRcra5sLmfFc51YP5nvqNee9W1Xzw9ATEu2mwuZ pmPx5z0R2t2+Lpy0ggkZQ4nq6iOUO7GmIuPShVG4uw== =7IWe -----END PGP SIGNATURE-----