[refpolicy] How to handle glibc-triggered behavior?

[dac.override@gmail.com (Dominick Grift)]

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

On Thu, Dec 10, 2015 at 04:20:39PM +0100, 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?
> > >
> > > Wkr,
> > > 	Sven Vermeulen
> > I'm bumping this again topic again.
> > 
> > Is there anything blocking a fix for this?
> 
> I like the idea but i think "domain" should not be used for this.

I am for creating a common_domain type attribute that inherits
"domain", then associate all non-mandatory common permissions with
common_domain.

This will give people options.

I wouldnt use domain for this becuase this sets a precedent. Today it
will be this but there are similar requirements imagineable, and similar arguments
may be used later to expand this even further.

rules common to shells, and a less applicable java for example.
Where to draw the line?

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

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

iQGcBAEBCgAGBQJWaZpCAAoJENAR6kfG5xmc+lkL/RYhAiM9DGQxYIfVKYSgyI9P
gP6ax6RFXnfR/WteDhFttPgVl+8fS6NV0j1BkAB1V+cBrt1JI5YY1sUmbh4lYTAr
/TJHcmB3tQdw4FVuKfR5+yyGFHrLYbytWN8fATHEqmM+aJ1UVHCiNKWJCfro5oYa
4iC+cY/Rtdw131BOSO4w6k8jAtgF/LhIaRlLT1x8VuuH/Ek+yNfVAtXmbRXK7SZ5
6IaXxFDagA0MFbueyw/pHz35J0yb2IJB6ww1QJYSytYb/R4WRXBWAywzboNiqmUl
GnbJoxwSWTFLcBG1Bfi6Q5i3agiaus/P/D4p3poFVviL4tmTQgowoIPIf4F3fbsh
LzyVeHH5OxRulP9NCTIJM52ouup01ZuMUm92ouTDYyB0Zh3CHK5jcUClM1rpcm4a
vBHZt5XJL8fQEwZIPrKau+8wfNUyKNuxxcgYQHlWxvD1HEvWCCp5S/RzEnV2DmcX
UVF7KWWfb5dSksQTu5H7tmhCjZBFwCuJwNxTwde6eA==
=wkxu
-----END PGP SIGNATURE-----