From: bigon@debian.org (Laurent Bigonville)
Date: Thu, 10 Dec 2015 15:59:33 +0100
Subject: [refpolicy] How to handle glibc-triggered behavior?
In-Reply-To: <20141221121526.GA5564@siphos.be>
References: <20141221121526.GA5564@siphos.be>
Message-ID: <56699355.6010402@debian.org>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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?
>
> Wkr,
> 	Sven Vermeulen
I'm bumping this again topic again.

Is there anything blocking a fix for this?

Cheers,

Laurent Bigonville