From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Wed, 27 Apr 2016 14:39:02 -0400
Subject: [refpolicy] [Patch V2 1/1] Add hwloc-dump-hwdata SELinux policy
In-Reply-To: <e467300d-6942-7f16-2739-e04cceaa6d7c@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>
	<57210055.2010808@tresys.com>
	<e467300d-6942-7f16-2739-e04cceaa6d7c@gmail.com>
Message-ID: <57210746.9030201@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 4/27/2016 2:30 PM, Dominick Grift wrote:
> On 04/27/2016 08:09 PM, Christopher J. PeBenito wrote:
> 
>>>
>>> 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.
> 
> 
> So now that i have accepted your point of view let me explain why I do
> not do this with DSSP
> 
> I do not give blanket access to sysadm to maintain all of /var/run,
> this is part of my ".adm()" implementation.
> 
> managing services can be done on an individual level in DSSP
> so hwloc.adm() can manage /var/run/hwloc (and when i mean "manage" i
> mean rm -rf /var/run/hwloc && mkdir -Z /var/run/hwlok) but not
> /var/run/http
> 
> sysadm is (almost) merely the accumulation of all the ".adm()" macros
> available.
> So if i would give sysadm blacket /var/run access then that would just
> be duplicate because sysadm can already manage it via the ".adm()"
> macro calls.
> 
> I think though that your approach explained above seems a little
> inconsistent with your desire to not give login users "blanket" access
> to user content via for example: userdom_manage_all_home_content()
> userdom_relabel_home_content()
> 
> In that instance you do want to give access on individual basis
> example: firefox.manage_home_content() firefox.relabe_home_content()

This is a good point; I would prefer that sysadm also be a collection
calls to admin() interfaces too, and it has slowly been moving that way.
 Hopefully we we will be able to eliminate the blanket access some time
in the future.  However, the interface we're talking about is not the
hwloc_admin() interface.  I would be fine changing this interface into
the hwloc_admin() interface.

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