From: dac.override@gmail.com (Dominick Grift) Date: Tue, 15 Aug 2017 17:44:43 +0200 Subject: [refpolicy] refpolicy and intrusive changes since Linux 4.12 Message-ID: <20170815154443.GA25875@julius.enp8s0.d30> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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