From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Thu, 10 Dec 2015 10:44:36 -0500
Subject: [refpolicy] How to handle glibc-triggered behavior?
In-Reply-To: <20151210151306.GB22216@x250>
References: <20141221121526.GA5564@siphos.be> <56699355.6010402@debian.org>
	<20151210151058.GA22216@x250> <20151210151306.GB22216@x250>
Message-ID: <56699DE4.7070109@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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?

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com