From: dac.override@gmail.com (Dominick Grift)
Date: Wed, 16 Aug 2017 09:19:30 +0200
Subject: [refpolicy] refpolicy and intrusive changes since Linux 4.12
In-Reply-To: <826c2b74-0e53-9ff3-05b5-188c535c46fd@ieee.org>
References: <20170815154443.GA25875@julius.enp8s0.d30>
	<826c2b74-0e53-9ff3-05b5-188c535c46fd@ieee.org>
Message-ID: <20170816071930.GA18987@julius.enp8s0.d30>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Tue, Aug 15, 2017 at 06:41:56PM -0400, Chris PeBenito via refpolicy wrote:
> 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.
> 

Thanks for clarifying. I would probably say "relatively few in at least core server systems", but other than that i agree that its not so much the volume as the spread. Theres a lot of "optional" domains that probably arent as exposed as others that may or may not need it, and from that perspective i do expect to see map denials here and there for quite some time to come

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

I see that as an option too. However if there are rules that reference both "cap_dac_override" as well as "cap_dac_read_search" (not saying that there are, but if there are any) then that is a bug by definition.

But yes agreed that for other instances dac_read_search denials will show up, and that then presents us with an oportunity to address these events properly for once and for all

Its going to take linger on for a while i suspect though, since like with map the optional domains that arent used much will probably take longer to get fixed.

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

glad to hear

> 
> -- 
> Chris PeBenito
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20170816/4972d045/attachment.bin