[refpolicy] How to handle glibc-triggered behavior?

[cpebenito@tresys.com (Christopher J. PeBenito)]

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