From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Thu, 10 Dec 2015 10:53:16 -0500
Subject: [refpolicy] How to handle glibc-triggered behavior?
In-Reply-To: <20151210154001.GE22216@x250>
References: <20141221121526.GA5564@siphos.be> <56699355.6010402@debian.org>
	<20151210154001.GE22216@x250>
Message-ID: <56699FEC.4070701@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 12/10/2015 10:40 AM, Dominick Grift wrote:
> On Thu, Dec 10, 2015 at 03:59:33PM +0100, Laurent Bigonville wrote:
>> Hey,
> 
>> Le 21/12/14 13:15, Sven Vermeulen a ?crit :
>>> 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?
>>>
>> I'm bumping this again topic again.
> 
>> Is there anything blocking a fix for this?
> 
> if we decide to do anything like this then lets start by implementing a
> proc_vm_overcommit_t type and associate that with
> /proc/sys/vm/overcommit_memory so that we have more control over this.

There are a couple things:
* Yes, to address this, it would warrant adding a new type for the
sysctl, though I'd probably call it sysctl_vm_overcommit_t.
* This should trigger some auditing of domains that have access to
sysctl_vm_t to see if it is only because of this sysctl, and if so,
adjust the access accordingly.

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