From: sven.vermeulen@siphos.be (Sven Vermeulen)
Date: Sun, 21 Dec 2014 13:15:26 +0100
Subject: [refpolicy] How to handle glibc-triggered behavior?
Message-ID: <20141221121526.GA5564@siphos.be>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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.

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

Wkr,
	Sven Vermeulen