From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-93021-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 62668 invoked by alias); 11 Jun 2018 07:28:33 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 61981 invoked by uid 89); 11 Jun 2018 07:28:32 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=
X-HELO: mx1.redhat.com
Subject: Re: [PATCH v4] Improve DST handling (Bug 23102, Bug 21942, Bug 18018,
 Bug, 23259, CVE-2011-0536 ).
To: Carlos O'Donell <carlos@redhat.com>,
 GNU C Library <libc-alpha@sourceware.org>, Andreas Schwab <schwab@suse.de>,
 "Dmitry V. Levin" <ldv@altlinux.org>
References: <9cf43cb6-511c-ec6c-9a87-e89a467238d9@redhat.com>
 <cce5064a-c6c8-6676-5088-d737b9a7c259@redhat.com>
 <e1c08bd2-2010-8ba9-5d44-6826aafe5bc5@redhat.com>
 <107904af-fe47-f7c4-e9ca-0fca03c61d4b@redhat.com>
 <c03b7f4a-d129-b24b-b2d8-f55bcf5b2456@redhat.com>
 <1492a272-6aa4-54c6-3849-4402f46d5282@redhat.com>
 <094272cc-7ec7-ebc5-d896-275b139892d7@redhat.com>
 <a98a01e8-7358-b848-6778-5bdf21d633be@redhat.com>
From: Florian Weimer <fweimer@redhat.com>
Message-ID: <2ca2dfa9-2066-9cfb-9851-6dc8415b1085@redhat.com>
Date: Mon, 11 Jun 2018 07:28:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <a98a01e8-7358-b848-6778-5bdf21d633be@redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-SW-Source: 2018-06/txt/msg00175.txt.bz2

On 06/11/2018 04:54 AM, Carlos O'Donell wrote:
>>> I consider the following valid:
>>>
>>> [$ORIGIN/../$LIB]
>> I'm actually asking about this:
>>
>> [$LIB:$ORIGIN/../$LIB]
>>
>> Doesn't the current code reject this?
> The current code does not reject this. In fact it accepts $LIB in RPATH
> et. al. because there is no code to reject it. Only $ORIGIN has any
> restrictions.

I meant the $ORIGN part.  As far as I understand it, start will not be 
close to input for the second part containing origin (after the :), so 
this check in _dl_dst_substitute should reject it:

		      || (input != start + 1
			  || (input > start + 2 && input[-2] != ':'))))

I'm not sure that this is right.

> Should all paths get tested for trusted paths for a SUID/SGID binary?
> It seems like that's the right idea.
> 
> @@ -365,7 +383,8 @@ _dl_dst_substitute (struct link_map *l, const char *start,
>  
>    /* In SUID/SGID programs, after DST expansion the normalized
>       path must be rooted in one of the trusted directories.  */
> -  if (__glibc_unlikely (check_for_trusted)
> +  if (__glibc_unlikely (__libc_enable_secure)
> +      && l->l_type == lt_executable
>        && !is_trusted_path_normalize (result, wp - result))
>      {
>        *result = '\0';
> 
> Just drop check_for_trusted, and execute the is_trusted_path_normalize
> check for all SUID/SGID paths?

No, $ORIGIN in a trusted path is itself trusted (because you cannot 
manipulate it using hard links).  I think there are installations out 
there which depend on this.

Thanks,
Florian