This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] tunables: Fix environment variable processing for setuid binaries
- From: Siddhesh Poyarekar <siddhesh at sourceware dot org>
- To: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 1 Feb 2017 10:23:42 +0530
- Subject: Re: [PATCH 1/2] tunables: Fix environment variable processing for setuid binaries
- Authentication-results: sourceware.org; auth=none
- References: <1485709870-25804-1-git-send-email-siddhesh@sourceware.org> <1485709870-25804-2-git-send-email-siddhesh@sourceware.org> <51584556-1411-112c-cc30-d19c93b1298b@redhat.com>
- Reply-to: siddhesh at sourceware dot org
On Tuesday 31 January 2017 10:21 PM, Florian Weimer wrote:
> On 01/29/2017 06:11 PM, Siddhesh Poyarekar wrote:
>> #if TUNABLES_FRONTEND == TUNABLES_FRONTEND_valstring
>> +# define ALLOC_SIZE 4096
>> +/* Allocate bytes on heap to store tunable values copied over from the
>> + valstring. We use a hardcoded ALLOC_SIZE to avoid querying the
>> page size,
>> + since it may not be available this early in the startup process. */
>> +static char *
>> +copy_to_heap (const char *in, size_t len)
>> +{
>> + static size_t heap_size = 0;
>> + static char *heap = NULL;
>> + char *out;
>> +
>> + if (heap_size < len + 1)
>> + {
>> + size_t ext = ALIGN_UP (len + 1, ALLOC_SIZE);
>
> Is this really necessary? That means that the tunable allocations are
> fairly substantial.
It is just a minor optimization - instead of allocating for every copy,
we allocate 4K at a time and then copy as we see fit. We will end up
copying a total length < 2xlength of the tunable string so in most cases
this should only be a single 4K allocation.
>> + /* If we are in a secure context (AT_SECURE) then ignore
>> the tunable
>> + unless it is explicitly marked as secure. Tunable values take
>> + precendence over their envvar aliases. */
>> + if (__libc_enable_secure)
>> + {
>> + if (cur->security_level == TUNABLE_SECLEVEL_SXID_ERASE)
>> + {
>> + char *q = &p[len];
>> + while (*q != '\0')
>> + *name++ = *q++;
>> + name[0] = '\0';
>> + len = 0;
>> + }
>> +
>> + if (cur->security_level != TUNABLE_SECLEVEL_NONE)
>> + continue;
>> + }
>
> This does not quite work because the next read position is not updated,
> although the tunable definition in the input string has been moved. As
> a result, a subsequent tunable is not recognized and applied or filtered.
Ugh right, I'll post an updated patch.
Siddhesh