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.
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
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
Also consensus on how refpolicy will address this from now on.
It should be eas(y|ier) from Linux 4.12 to identify whether cap_dac_override is needed or whether cap_dac_read_search would suffice
There should atleast not be any instances where a type is associated with both cap_dac_override as well as cap_dac_read_search if there are any
[1] https://github.com/TresysTechnology/refpolicy/commit/7a4e93a385ff186c6dc8c5b36bdd4461eec251c3
--
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/20170815/016d8ba8/attachment.bin
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
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