From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) by sourceware.org (Postfix) with ESMTPS id E1F373858427 for ; Thu, 25 Nov 2021 17:56:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E1F373858427 Received: by mail-ua1-x92e.google.com with SMTP id t13so13851599uad.9 for ; Thu, 25 Nov 2021 09:56:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=0P2Rm4R8zjxKmxzDpzit3zlD0Y16IMhPRNdo2VqfOOM=; b=DjYmJQRJ26KSHjkrpN8uzQaHFT3kjydkvnm3aPmgdXLDwrKSEvFQLcENg5kJ8fsz4a RBuAxb8g6hiAn1WxOrq51msmF7K8jwIP8ESnya7unRoiarRBCgiyOrmrlNBwUYXUrP2t OINdl+ep7DsrvBxYMKUcBJ04z+Ksy5yZdwYx9duU0m3+eEYxUWD8q0OQdhoLH2I3L8OG 1qVvu7HyVtYRwnxMe3ylBMVkBj+2+FzrkSOqD/WfCstywWUk5jydJ8MGB7/n7xN8+2U7 qmsgICOz5svqmOZXpo3gd5x4TyrpZsWX0d0Eh2g4MVW8wpNuHjNZG4l1uHZyxFRStr6o 4CwA== X-Gm-Message-State: AOAM533cjY0FPQKpktL4it53DgnetNZZnJkC0obo0sYJkEoAkd8WPGmV fWsTg8Ky8lIsyOfKi7L43fmPs1ixIYHaMw== X-Google-Smtp-Source: ABdhPJx2R7bhq8/I+EVLJ2VyWuxP4Ti/x9qhKdrApPZ6bypRNzCCNjlmsLidXCXaV0EEOicZKdLZYQ== X-Received: by 2002:ab0:29d3:: with SMTP id i19mr28480022uaq.75.1637862995463; Thu, 25 Nov 2021 09:56:35 -0800 (PST) Received: from ?IPV6:2804:431:c7cb:e054:f9cd:8920:996d:94da? ([2804:431:c7cb:e054:f9cd:8920:996d:94da]) by smtp.gmail.com with ESMTPSA id w2sm2028477vsw.29.2021.11.25.09.56.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Nov 2021 09:56:35 -0800 (PST) Message-ID: Date: Thu, 25 Nov 2021 14:56:31 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: Fwd: [PATCH v5 00/22] Some rtld-audit fixes Content-Language: en-US To: Jonathon Anderson , Florian Weimer Cc: jma14 , John Mellor-Crummey , libc-alpha@sourceware.org, "Mark W. Krentel" , Xiaozhu Meng References: <20211122114629.Horde._rW0tgxbf_wCwsiLyKcms3g@webmail.rice.edu> <87tug3rmv7.fsf@oldenburg.str.redhat.com> <87sfvmrf2u.fsf@oldenburg.str.redhat.com> <23fab3f4-edf6-c34e-7cbd-2dee4bc9457e@rice.edu> From: Adhemerval Zanella In-Reply-To: <23fab3f4-edf6-c34e-7cbd-2dee4bc9457e@rice.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2021 17:56:37 -0000 On 23/11/2021 18:13, Jonathon Anderson wrote: >> On 22/11/2021 14:46, jma14 wrote: >>> On 11/19/21 14:31, Florian Weimer       wrote: >>> >>>> * Adhemerval Zanella: >>>>>> "" for the main executable is widely known.  Usually code uses it to >>>>>> implement a fallback on argv[0] or /proc/self/exe, though. >>> If this is widely known, it would be helpful if this was added to the man pages. Currently the man pages define l_name as the "absolute pathname where object was found." That sounds (to me at least) like dlinfo(dlopen(NULL)) is a portable alternative to the Linux-specific AT_EXECFN, contrary to reality. >> To provide an absolute pathname it would require to use realpath() or similar >> strategy either before issuing la_objopen() or while parsing the arguments >> or reading AT_EXECFN. I am not sure if this best approach, specially if the >> executable is executed through a namespace or any kernel abstraction where >> obtaining the full path though filesystem walk is not possible or restricted. > I had interpreted this as l_name may not necessarily be a canonical path. To me, the wording "was found" indicates that this is the path resulting from library search, in effect .../libfoo.so.1 instead of the canonical .../libfoo.so.1.2.3. Currently l_name is not always absolute if the search involved a relative path, which I also consider an issue either in documentation or behavior (also affects dladdr). > > Under this interpretation I don't see a need to use realpath() (at most getcwd()), if a user requires a canonical path they can call realpath() themselves. They already need to be robust against the possibility that the file was deleted/replaced right after it was loaded, deleted/replaced symlinks are a reasonable extension to that. Linux at least appends '(deleted)' if the pathname has been unlinked. > > On 11/23/21 10:50, Florian Weimer wrote: >> * Adhemerval Zanella: >> >>> On 23/11/2021 11:02, Florian Weimer wrote: >>>> * Adhemerval Zanella: >>>> >>>>> In fact I think rather than using the argv[0], since it passing the >>>>> executable path is just a convention; I think it would be better to >>>>> use AT_EXECFN. On recent kernel it is always passed to userland and >>>>> kernel should be responsible to hide any filesystem information if it >>>>> is required. >>>> It's still a relative path to an unknown directory, I think. I expect >>>> (but have not checked) that it is the pathname argument to execveat, >>>> which may not be meaningful to the new process image. > execveat seems to generate an AT_EXECFN under /dev/fd, it has no meaning in the new process image if O_CLOEXEC is used on the directory file descriptor. Under the interpretation above I think this is reasonable. >>>> Yes, but it better than _dl_argv[0] and/or an empty string. Without >>>> proper kernel support we can not reliable get the path, in fact the >>>> kernel might in fact hides it on purpose. >> I'm worried that if we put a path-looking string there, programmers will >> assume it is THE path to the executable. With SUID programs, that looks >> like a recipe for security vulnerabilities. These users need to use >> /proc/self/exe and give up if that's not available. > I do not think l_name is unique in this concern, AT_EXECFN and dladdr expose the same security risk and AFAICT this is not noted in either of their man pages. > > I'm not familiar with all the security constraints surrounding SUID, but as a simple but effective resolution I would consider setting the executable's l_name to the string "/proc/self/exe" in secure-execution mode. A similar change could be done in getauxval() to transparently modify AT_EXECFN. Those two changes would force all unwitting SUID users to (semi-gracefully) fail when /proc is unavailable. I think this is fair assumption.