[refpolicy] [Patch V2 1/1] Add hwloc-dump-hwdata SELinux policy

[dac.override@gmail.com (Dominick Grift)]

-----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 @@ +## <summary>Dump
>> topology and locality information from hardware
>> tables.</summary> + +######################################## +##
>> <summary> +##	Execute hwloc dhwd in the hwloc dhwd domain. +##
>> </summary> +## <param name="domain"> +##	<summary> +##	Domain
>> allowed to transition. +##	</summary> +## </param> +# 
>> +interface(`hwloc_domtrans_hwloc_dhwd',`
> 
> I would name this hwloc_domtrans_dhwd.

fair enough
> 
> 
>> +######################################## +## <summary> +##
>> Manage hwloc runtime. +## </summary> +## <param name="domain"> 
>> +##	<summary> +##	Domain allowed access. +##	</summary> +##
>> </param> +# +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-----