From: dac.override@gmail.com (Dominick Grift)
Date: Wed, 27 Apr 2016 20:12:58 +0200
Subject: [refpolicy] [Patch V2 1/1] Add hwloc-dump-hwdata SELinux policy
In-Reply-To: <57210055.2010808@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>
	<78d8575f-2650-81c7-1be1-176108885041@gmail.com>
	<57210055.2010808@tresys.com>
Message-ID: <7de2d9d9-c769-d7e1-6f12-eed21526320e@gmail.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/27/2016 08:09 PM, Christopher J. PeBenito wrote:
> On 4/27/2016 1:42 PM, Dominick Grift wrote:
>> On 04/27/2016 07:33 PM, Christopher J. PeBenito wrote:
>>> On 4/27/2016 11:21 AM, gandrejc wrote:
>> 
> 
>>>> +######################################## +## <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.
> 
> I'm fine with the lnk_file permissions, but I see this interface
> as applying to the contents of the top level directory.  Though if
> there are subdirectories, the're isn't a good enough reason to
> distinguish the top from sub directories.
> 
> 
>>> 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.
> 
> I understand the desire to be flexible, but this doesn't give us
> the chance to be more restrictive.
> 
> Ultimately I'm not persuaded simply because sysadm can already
> manage all these files. I'd like to reduce sysadm's access, but I
> think the blanket pid access makes sense.  Splitting into two or
> three interfaces is more flexible from the policy writing
> perspective, and the flexible (from the runtime perspective)
> behavior you describe above is what is desired, then all of the
> interfaces can be called.  Then we still have room for more
> restrictive cases.
> 

Fair enough


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

iQGcBAEBCAAGBQJXIQElAAoJECV0jlU3+UdpZXUL/0IA4cLrNn1OWE7pqxvKdL4W
01DNtCmtrYc2PUylx3jlY2D5Nkn4Rmlu8txPMJjZH2URMP1u2kqHj30M/8fxPXK1
Pt7C9P7RKIWzd/Am9bKLYcrfMpW/U/n1n/0t/iM7M/UVk/xfXwXsodJLPQNtxmlw
UYL0aM/iAz9u4fuiYFpy8f/qu6/L26N0xMkIE99jc9KGeMQ3qdyjPoHYYvqbovii
VgK6lt2uw1xpZ72t8RzuxQ4Bp1eYnEKCKp+Z0+XQvAp/MxSv8ApC75Eg38+g9d4i
0Hs4yKYy8RFYOgOjkpC6naBfJwUQEIdM0k9D0abQeaX9neuBQzIfXxvSHjYRvhZA
rIj2TrrpoOUB5VHWVqr8q3Q32bjxOl5Lw1MTqk1RIjWR7Z1vga4UbQAoo/endMzC
q/bTAbhAVtq2LXP2lIdEQ0yRHzOP6qTU36mr2HUbQR8C1P8QSPZ/zMDavf4HmV7a
YWxSok7Xe55oHfxy/5+zzhNQDtPlOTdP+xECiNaUKA==
=BAC9
-----END PGP SIGNATURE-----