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-----