From: dac.override@gmail.com (Dominick Grift)
Date: Thu, 10 Dec 2015 16:11:00 +0100
Subject: [refpolicy] How to handle glibc-triggered behavior?
In-Reply-To: <56699355.6010402@debian.org>
References: <20141221121526.GA5564@siphos.be>
 <56699355.6010402@debian.org>
Message-ID: <20151210151058.GA22216@x250>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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

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

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

iQGcBAEBCgAGBQJWaZX+AAoJENAR6kfG5xmcn3kL/j4le20hA7AZKfDW2DPqAOm7
gAAvyAWfDw8UyDxQalfVKu8TvO26msG35QbF3iZQikHpNov4mmnzK/OTRwDcRfL9
LzdvJ8FafxhputhjqfA0Mr+wwOHRwGkKgcDjCtHYVmEKHmwWikHRiP6tCNVnmk8S
qZfExk+67qwojPSYn+7CqE/Muh0IcNDQkzmBKvlpqckr6vOfo1dbNQuwgW6+dLPL
7gU6QkNSyksnZkyl0sR4O1YhioBEAJ97nzG1VVVN+T6q/N4GaqqcMeJ8a9NVvCiy
avOAlJwrs6XxFg+/28Ep5x2WjNxUxIr623Ya4YEkXNchK/Gdwh0P5seMILHECJm+
ODSiItPCgW+5G2uOMJaLhGy0ybeAouthm9Zfkcg0mYpqSJI82fjPV9bqr8tMvtC6
dJwgI6BqKk8dLWriaYGkbWwRN2YU1tT+SKjZi+taAuQESoCufYzoETvy49rAqeSq
yW1CBcBS6VACLrHfFcwg563NLQPsTCWntFu9J824UQ==
=xH8q
-----END PGP SIGNATURE-----