(~amd64 packages, git hardened reference policy) Upon restart of the named service, I am seeing a few denials on letting it see certain sysctls: Nov 15 17:42:32 testbed kernel: [34350.395786] audit: type=1400 audit(1416094952.861:130): avc: denied { search } for pid=3276 comm="named" name="vm" dev="proc" ino=4679 ipaddr=173.173.113.156 scontext=system_u:system_r:named_t tcontext=system_u:object_r:sysctl_vm_t tclass=dir permissive=0 Upon granting kernel_search_vm_sysctl(named_t), we see what it really wants: Nov 15 17:59:37 testbed kernel: [35375.786298] audit: type=1400 audit(1416095977.441:133): avc: denied { read } for pid=7860 comm="named" name="overcommit_memory" dev="proc" ino=871 ipaddr=173.173.113.156 scontext=system_u:system_r:named_t tcontext=system_u:object_r:sysctl_vm_t tclass=file permissive=0 Which kernel_read_vm_sysctls(named_t) solves. Given that it already had a bevy of kernel_read_* interfaces present for reading /proc, we might as well do it right! Patch: diff --git a/policy/modules/contrib/bind.te b/policy/modules/contrib/bind.te index bfb927f..d7c05d8 100644 --- a/policy/modules/contrib/bind.te +++ b/policy/modules/contrib/bind.te @@ -109,6 +109,8 @@ allow named_t named_zone_t:dir list_dir_perms; read_files_pattern(named_t, named_zone_t, named_zone_t) read_lnk_files_pattern(named_t, named_zone_t, named_zone_t) +kernel_search_vm_sysctl(named_t) +kernel_read_vm_sysctls(named_t) kernel_read_kernel_sysctls(named_t) kernel_read_system_state(named_t) kernel_read_network_state(named_t) Reproducible: Always
Does the daemon fail or give any errors if it is not granted? Otherwise dontaudit is also a solution, and doesn't increase the privileges of the domain. Also, overcommit_memory tests look like something libc related (i.e. could also be due to the use of libraries rather than being named specific).
It does not appear that bind crashes without those privileges, *HOWEVER*, I am not using bind in an extreme scenario as all it is doing is caching. My use cases are generally narrowly tailored, which means I'm not seeing the whole extent of what the application does. BIND does need some memory management stuff because it manages an internal cache and likes to resize things a lot, and I expect that the sysctl information is useful. It is unclear how it handles denials, but just because it isn't a crash does not mean the result is a good one. I feel it is simpler to just give bind the sysctl access it wants rather than haggle over whether it is or is not an actual issue then sort out whether any issues happen with dontaudit scenarios. This is because from my point of view, giving read-only access to some kernel sysctls is not a significant expansion of privileges, nor is it a privilege set that could be meaningfully used if the service were compromised.
Looks to be glibc. Glibc uses memory "arenas" to allow for multi-threaded applications to have per-thread memory pools (arenas) so that there is no contention in accessing memory between threads. When requesting memory from the non-main arena (i.e. the main process heap) glibc will call heap_trim -> shrink_heap -> check_may_shrink_heap which reads in the overcommit_memory setting to see how to behave. For applications that use it, granting read access to overcommit_memory (sysctl_vm_t) is warranted, as system administrators might tweak/tune the memory settings of the system yet not see the expected behavior from applications (or perhaps even bad results) in the memory management area. I've asked upstream how to tackle this, as this is a glibc-related aspect, not specifically BIND (named). However, I do agree that granting read access is needed here - I just need to see at which "location" in the policy and how it will be granted.
http://oss.tresys.com/pipermail/refpolicy/2014-December/007530.html Upstream request
http://oss.tresys.com/pipermail/refpolicy/2015-January/007559.html I'll add it in for all domains
It's in the next branch for now, need to update my test VMs first
in ~arch
r4 is stable
