From: pebenito@ieee.org (Chris PeBenito)
Date: Tue, 15 Aug 2017 18:41:56 -0400
Subject: [refpolicy] refpolicy and intrusive changes since Linux 4.12
In-Reply-To: <20170815154443.GA25875@julius.enp8s0.d30>
References: <20170815154443.GA25875@julius.enp8s0.d30>
Message-ID: <826c2b74-0e53-9ff3-05b5-188c535c46fd@ieee.org>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 08/15/2017 11:44 AM, Dominick Grift via refpolicy wrote:
> The patch from Stephen Smalley [1], accepted by refpolicy implies that refpolicy intends to leverage the map permission
> 
> It looks to be a lengthy process to add support for map, where desired, tree wide.

My suspicion is that other than for shared objects and executables 
(which is already addressed in that patch), there is very little 
mmapping that happens in most systems; hopefully few enough that not 
having it in the permission set macros wouldn't be too painful to 
resolve.  Because of that, I suspect the majority of the perms are 
already addressed.


> Since Linux 4.12, the order of checks for cap_dac_override and cap_dac_search has been switched. This change decreases chances that dac_override is granted where dac_read_search would have sufficed
> 
> People using refpolicy with Linux 4.12 will, i suspect, see many cap_dac_read_search denials due to this change
> 
> The question i would like to pose is: how should refpolicy deal with this change?
> 
> I suggest that we change all cap_dac_override occurences to cap_dac_read_search *unless* there is strong proof in the policy that indicated that dac_override is needed.
> 
> One of such instances would be setuid/setgid applications maintaining state/stateless files
> 
> But we could also just be on the safe side and replace all of the cap_dac_override occurences with cap_dac_read_search

I'm not sure there is a reasonable way to address current policy other 
than testing.  I'm not inclined to make any changes that aren't based on 
testing.


> The clarification i would like to have is whether refpolicy intends to leverage this cap_dac_override/cap_dac_read_search Linux 4.12 change

Yes.


> Also consensus on how refpolicy will address this from now on.

Nothing different than has usually be done for capabilities: least 
privilege.

-- 
Chris PeBenito