[refpolicy] How to handle glibc-triggered behavior?

[cpebenito@tresys.com (Christopher J. PeBenito)]

On 12/21/2014 7:15 AM, Sven Vermeulen wrote:
> glibc's malloc implementation, in multithreaded applications, might read
> /proc/sys/vm/overcommit_memory to check if the heap can be shrunk or not
> (when the allocated memory is part of the non-main arena). That means that
> read access to sysctl_vm_t becomes a wide request.
> 
> Not granting privileges might result in different memory behavior, where the
> system administrator might have tuned/tweaked memory allocations on Linux,
> but malloc() ignoring this due to SELinux denying access to the settings.
> 
> I'm wondering how to properly tackle this. Granting this on a per-domain
> level is probably not manageable, but granting this for all domains (through
> the "domain" attribute) might be overshooting.

Since typically everything is linked against glibc, and adding read
doesn't seem to be very concerning, I'd tend to do the latter.

> Are there specific risks that I should take into account when granting read
> access to sysctl_vm_t?

Looking through the sysctls, I don't really see much to be concerned
about.  Knowing all the virtual memory settings doesn't seem like it
would make any easier to do a denial of service attack.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com