Summary: | named kernel sysctl access denials | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Eric Gisse <jowr.pi> |
Component: | SELinux | Assignee: | Sven Vermeulen (RETIRED) <swift> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | selinux |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | sec-policy r3 | ||
Package list: | Runtime testing required: | --- |
Description
Eric Gisse
2014-11-16 00:06:25 UTC
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 |