From: dac.override@gmail.com (Dominick Grift)
Date: Thu, 10 Dec 2015 16:40:02 +0100
Subject: [refpolicy] How to handle glibc-triggered behavior?
In-Reply-To: <56699355.6010402@debian.org>
References: <20141221121526.GA5564@siphos.be>
 <56699355.6010402@debian.org>
Message-ID: <20151210154001.GE22216@x250>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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?
> >
> > Wkr,
> > 	Sven Vermeulen
> 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.

> 
> Cheers,
> 
> Laurent Bigonville
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWaZzNAAoJENAR6kfG5xmcZVUMAMK1E9/eKK3eOGhvvP5q5SIX
xohoA7frNADiwQ2/srwkBERnb29aW9wY7Odg1opz50+abQnqtJcOSV5LXDTFVnc3
PqO/E+MCNzHJ4jqi0tocAz0W0Ih65bd+2qhX4cLSzT+1K2rdX/K9ZjlLQ+fjA5XK
sx7iJ3yp9yGuoESz9e4F6nBYjxpNQe0zboTLaxo9XHxXz3dvIn3OB+XjioFDPRRI
doZjpMttdQ84z8bqLDq7j8wmujnxuyQp7KxbiFJfML0yFXjKixWhHMmgT+fgAVU4
oKOB3KVT5RGoqQxSJqh4o3OLOVUGTSZSeA05/FBb7pADMvqAteMttwzNIE/GtXNx
FJV7FVgC/L8++8Ji8jC1dFvPrU0cw+7qf3jDH4xxzWOyHzL6UqL5kxeeWq9xYlUO
Iz+dY+QztOLeWro8BRKFIArWPgOP/9wSqIABo2pj1E78xMTfWrBHOxzLZyQe0rvi
pR96zPNHS3X/CiDlAfx6t5LWJsoPvWBJlnGBK4Pqhw==
=0PKT
-----END PGP SIGNATURE-----