From: dac.override@gmail.com (Dominick Grift)
Date: Thu, 10 Dec 2015 16:49:09 +0100
Subject: [refpolicy] How to handle glibc-triggered behavior?
In-Reply-To: <56699DE4.7070109@tresys.com>
References: <20141221121526.GA5564@siphos.be> <56699355.6010402@debian.org>
	<20151210151058.GA22216@x250> <20151210151306.GB22216@x250>
	<56699DE4.7070109@tresys.com>
Message-ID: <20151210154907.GF22216@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: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.

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWaZ7vAAoJENAR6kfG5xmcFv4L/1O7PJiIslAbT9yV8MEwAOn8
atxv4AHvdF5B5H+L0AVjqng11RUJssKMC+MQROUvwFk+CS6GmrGlI7USO+tSCmwl
Z3nK+y+3RyGItz3iOgC1JzaJWspRm4uv5bCRO+CsOQVLxGolxBs2yfFDRda2OHD4
Hxeij1IYa4BvLOMy+pOALk4BIsOOXBI4MJEPoigSB/Qt5WVprqm/WVk8doiSeqcb
QTl6uS3sENz7f2cIQiI2GOAelxDfeDAL1c+zDHOuPB0QAkCJ1rjasIPKwCfYnDrI
+vD/H2zKIa3ODHtKm6z3xHDqkiXdEHz1WW79otm2BreHEnpwkWoMFG2UPwKPmAUZ
jNQwg76Rz3MuJl5WuuZWyhi13DmzCiGLZiF5G6fFzVAbEVi953oFw4cYkQDfSd7D
k58gDO3mi4mJlB/6Nc6znu4Zj2JakusKdTZrDaMSoEnYGgBlV5tgXFrKn+JRMN9o
En8ZENdVVQ7SNeSi0m5EoVVWHEBlHFXekFiHyK/jxA==
=BHiO
-----END PGP SIGNATURE-----