From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Wed, 27 Apr 2016 14:09:25 -0400
Subject: [refpolicy] [Patch V2 1/1] Add hwloc-dump-hwdata SELinux policy
In-Reply-To: <78d8575f-2650-81c7-1be1-176108885041@gmail.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>
Message-ID: <57210055.2010808@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com