From mboxrd@z Thu Jan  1 00:00:00 1970
From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Mon, 12 Jan 2015 09:03:38 -0500
Subject: [refpolicy] How to handle glibc-triggered behavior?
In-Reply-To: <20141221121526.GA5564@siphos.be>
References: <20141221121526.GA5564@siphos.be>
Message-ID: <54B3D43A.5060203@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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