[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:10:58PM +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?
> 
> Is there no sysctl_vm_overcommit_t type for this in refpolicy
> 
> My concern is with associating this with "domain". I would like to
> associate as little rules as possible with type attribute for
> aforementioned reasons. (e.g. domain is mandatory attribute to associate
> with your process type you do not want to be in a position where you are
> forced to associate permissions with your type that you do not need)
> 
> What I would do, and what i do to some degree already in dssp, is
> 
> i would create various lower level client type attribute for various
> interpreters and glibs for example.
> 
> For example:
> 
> corecmd_shell_client_type will be associated with any process that
> executes a shell via corecmd_exec_shell()
> 
> rules like:
> 
> allow corecmd_shell_client_type self:fifo_file rw_fifo_file_perms;
> kernel_read_system_state(corecmd_shell_client_type)
> 
> will be associated.
> 
> So as soon as you call corecmd_shell_client_type, your process will
> already have rules common to executing a shell

I meant:

So as soon as you call corecmd_exec_shell(), your process will already
have rules common to executing a shell

> 
> the problem with this approach is the type attribute usage. You cannot
> associate type attributes with type attributes. Thus:
> 
> corecmd_exec_shell(myapp_domain)
> 
> would not work
> 
> 
> > >
> > > Wkr,
> > > 	Sven Vermeulen
> > I'm bumping this again topic again.
> > 
> > Is there anything blocking a fix for 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

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

iQGcBAEBCgAGBQJWaZZ9AAoJENAR6kfG5xmcunQL/jWPlmQuwrLo5AW9AhyOLRV5
XxxnS4Jc9D5HJ/PWQhJQQdbP2HmEZM0HINOzt5f1D+BPnMVuGt8bqOm5HNzX02op
ARz0ttu03Oo1Hh/+HdHJRaYQlUXqmyQCTXcCkXgErbbKS0+pGwedkuo/4ytw0Eyg
hvxRnav+ANbCXIUCtIdIzCJ18aLnHoRWKi79ZibkADmTgmGdW9RS7N3BlOcp6lxm
4ZtslGYHf8FjNd/ysTwMngC7rQlamhy+rQ1EmA0zmkVH8G+dGPxw85CXuxfb+nUe
PY2h8Ed+IKYBo5JqkIJ5F+lzCLXz7LRByqIKAoicY5IN99VRDWvL+OaFV2mJw2uN
Uq5TuHF4icNdoIFBGk1KGtcWGuBXZyzSIR9uGrNnOlka3M1H6/fefX5LO/dJ2v46
YIsAVI2qVlQJwUyXEIqgZdfTe86qmwZDFl5/cBiiyff5XL+E0++vz14mtMChnMUs
3pnfXpZ0JJkvJ2L6kxOtsXBf0rf2+Uhva5VrN8kijQ==
=Ea3h
-----END PGP SIGNATURE-----