[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:49:07PM +0100, Dominick Grift wrote:
> On Thu, Dec 10, 2015 at 10:44:36AM -0500, Christopher J. PeBenito wrote:
> > On 12/10/2015 10:13 AM, Dominick Grift wrote:
> > > 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
> > 
> > I suspect this is not a good choice.  The concept for this access is
> > multithreaded glibc-linked programs.  Are there any multithreaded shells?
> 
> I must not have been clear since I believe you misunderstood my point
> 
> This is not about one this or another. It is about associating common
> permissions.

s/this/thing

> 
> So proc_vm_overcommit may be common to multithreaded glibc apps, but
> kernel_read_system_state for example is common to shells.
> 
> So i am looking to this from the perspective of common rules (for
> whatever reason they may be common)
> 
> > 
> > -- 
> > 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

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

iQGcBAEBCgAGBQJWaZ92AAoJENAR6kfG5xmchQAL/RczosFKhacr222Xj11F2vCj
/fLfBQRqiR+J+/FwQvhVJGRqWepzfRKXGFMX3pBpEE85jXufZxORJRdGyfiBd/Qe
L1zg3Zdl0nLPzZuDh2WZzQwKIk4wYf3HlNwOPAuU9MamvA8aMqWg19BgFKckVnVJ
ULUDME3R55ijamme/73mxefjuuP/osSqBInjcQqHVbS1DkrgQOk1ZXRVFD/V9Pvg
H3bu/Sgl9YGEaTHEzTXlB8pWMH9N+Si2GH+VpDcTISAgVne9tT/ToemnjDnpk6K4
DUZ/Fjnb/XlSRm1xsA4OyHOEP/gupMEvZO7s44dTapv6wVnOkgcmVwSo/96ZBPUg
h7ZTU0Kc7hOIR/I4HAZQqRi/IKGV8K/O2E7CPR0HV3Ps39uhCxutXrv4kfPjd+2b
RdMq/RoBvhj8BWXyX8DDptSIV+9/649w+pO1aqr4ZTKiC89rhHTu7RgSEkeWEIpB
jslqUDzTmxDU9Kq+y8JQ7sGOc+XACtL3LHIz5JyPdQ==
=QHZE
-----END PGP SIGNATURE-----