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-----