From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-0010f301.pphosted.com (mx0b-0010f301.pphosted.com [148.163.153.244]) by sourceware.org (Postfix) with ESMTPS id 11D963858430 for ; Tue, 23 Nov 2021 21:14:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 11D963858430 Received: from pps.filterd (m0102859.ppops.net [127.0.0.1]) by mx0b-0010f301.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 1ANJNFGt006592; Tue, 23 Nov 2021 15:14:06 -0600 Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by mx0b-0010f301.pphosted.com (PPS) with ESMTPS id 3ch6dpr4uy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Nov 2021 15:14:05 -0600 Received-X: from mh2.mail.rice.edu (localhost [127.0.0.1]) by mh2.mail.rice.edu (Postfix) with ESMTP id 77413200D33; Tue, 23 Nov 2021 15:14:05 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by mh2.mail.rice.edu (Postfix) with ESMTP id 75637200D11; Tue, 23 Nov 2021 15:14:05 -0600 (CST) X-Virus-Scanned: by amavis-2.12.1 at mh2.mail.rice.edu, auth channel Received: from mh2.mail.rice.edu ([127.0.0.1]) by localhost (mh2.mail.rice.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4pBmgYR8LyV5; Tue, 23 Nov 2021 15:13:55 -0600 (CST) Received: from [76.30.156.87] (c-76-30-156-87.hsd1.tx.comcast.net [76.30.156.87]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jma14) by mh2.mail.rice.edu (Postfix) with ESMTPSA id 56F81200B8C; Tue, 23 Nov 2021 15:13:55 -0600 (CST) Message-ID: <23fab3f4-edf6-c34e-7cbd-2dee4bc9457e@rice.edu> Date: Tue, 23 Nov 2021 15:13:54 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: Fwd: [PATCH v5 00/22] Some rtld-audit fixes Content-Language: en-US To: Florian Weimer , Adhemerval Zanella 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> From: Jonathon Anderson In-Reply-To: <87sfvmrf2u.fsf@oldenburg.str.redhat.com> X-Proofpoint-ORIG-GUID: yvvGvxuA33--54PWT6gMsFQKfrM-J-jf X-Proofpoint-GUID: yvvGvxuA33--54PWT6gMsFQKfrM-J-jf X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-11-23_07,2021-11-23_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 clxscore=1011 suspectscore=0 phishscore=0 mlxlogscore=999 mlxscore=0 lowpriorityscore=0 spamscore=0 adultscore=0 priorityscore=1501 bulkscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2111230103 X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, NICE_REPLY_A, 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 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Tue, 23 Nov 2021 21:14:10 -0000 > 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. 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. -Jonathon