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

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

On Thu, Dec 10, 2015 at 10:53:16AM -0500, Christopher J. PeBenito wrote:
> 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.

I think we can reach a consensus on the above. first things first.

Then later we can discuss grouping this further if deemed necessary.

Are you going to submit a patch Laurent?

> 
> -- 
> Chris PeBenito
> Tresys Technology, LLC
> www.tresys.com | oss.tresys.com
> _______________________________________________
> 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

iQGcBAEBCgAGBQJWaaGQAAoJENAR6kfG5xmcrzML/1kTMpJCiJGPe3Qf18TtOz3g
IL8nfHclLCgpzzNlyTB7i+34FmwJiL6i4Qo1xrmod2t2v4wJd0yUJlMBw0C9f1vY
I3OFw99CitfnMzZoRixkCw/pvFrcVcrIrIeVZQz4V7KQlMTjHZkhKxk0vfxcx5OC
utKL6zSti54dSJluqnFVw6/4Vi7yOmLsA5YGOOdabbkb1/QNW8pw0JRvqu1XY9ED
43wDnRYYPmNUUMUX3d2eRpQhFm9O+uOyiRXtJFwzlVyEIbF0feBNCoI+j6OTQZpb
d9Rnevph3osOdF+G0783EsKUBxUs1NaBVhXt4rfxspAGcYPnvMlg35tKiU3urVS0
/L3ZGyqTCW2zEI85iKmQQQfDNhCr/VUzIrcAR00kJgib5C7f3eLee1F7CbHLGgKf
6UW74bbEBilYynGq4YJSikIbJRMzOykTx2omeRvfufsRGP1DFvFuyko9+4XTBI1/
K9dpleI05N3LDRJp4os1D6qh6EAnIBkkDXluL5OIIw==
=v7xP
-----END PGP SIGNATURE-----