From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) by sourceware.org (Postfix) with ESMTPS id 6D84A385802B for ; Tue, 23 Nov 2021 13:58:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6D84A385802B Received: by mail-ua1-x92d.google.com with SMTP id r15so43980686uao.3 for ; Tue, 23 Nov 2021 05:58:53 -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=2Ym6zzJViwhwfBEDOg+rt4TyDE92XPS2RhLqWzPaDyw=; b=hqWXH/HUsqw8XSX2wfWIYioY8gNCa2umwD8u/bTTkMltx3meX0V19Eruc0+qmncKj3 pNfiazcNguAbanDeYxxEX2rnPmUxy8P9rE/PIYbpvBmimjOQAppV0krNP0E5Qj8Dc5Bt FVJt6szNP/uQ/cy/WsGeelahiODSHCgrbikdCcgFOQ893lA4xUFQMGhv2D13nwR55n9e l0JJH3zYpnSnMBJoBHh06HnaLMqnA5xpc3FtWQVRK9C3sZgf/6mYB+ZNFTvevEzCFCIT scfWhjbS0NqY5qhuV3vHFIokmPfB2pwO/K/fKviroIC+j4S2mqSZ3Cy2NR0tlU9pmdSZ ye3A== X-Gm-Message-State: AOAM530st5TgBwd3/MNYZV5ixzYuggw2XApyGQqYA7C+RTFPmZczy07s Nq8d8KfcfHxvojkMk4aBC6Pq8A== X-Google-Smtp-Source: ABdhPJydsGfzr48mTfYSDGhfNq3W5N3FkFWkrw2Y3A8VnV901U8epGtPtonAxpco520VhTBTQz9QQw== X-Received: by 2002:ab0:6e92:: with SMTP id b18mr9296329uav.101.1637675932337; Tue, 23 Nov 2021 05:58:52 -0800 (PST) Received: from ?IPV6:2804:431:c7cb:e054:570f:87aa:2a8d:f2bc? ([2804:431:c7cb:e054:570f:87aa:2a8d:f2bc]) by smtp.gmail.com with ESMTPSA id x9sm6256799vkn.36.2021.11.23.05.58.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Nov 2021 05:58:51 -0800 (PST) Message-ID: Date: Tue, 23 Nov 2021 10:58:49 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: Fwd: [PATCH v5 00/22] Some rtld-audit fixes Content-Language: en-US To: jma14 , Florian Weimer Cc: John Mellor-Crummey , libc-alpha@sourceware.org, "Mark W. Krentel" , Xiaozhu Meng References: <20211122114629.Horde._rW0tgxbf_wCwsiLyKcms3g@webmail.rice.edu> From: Adhemerval Zanella In-Reply-To: <20211122114629.Horde._rW0tgxbf_wCwsiLyKcms3g@webmail.rice.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.0 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: Tue, 23 Nov 2021 13:58:55 -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. > >>> There are still the issue where audit interface does not have direct >>> access to argv[0] from the audited process and '/proc' might also not >>> be accessible.  I am still not convinced that provided argv[0] for >>> l_name for main executable is worse than "", specially because the >>> fallback might not work. >> >> I think it's better to give the auditor a chance to figure out whether >> they want to use program_invocation_name (if that's not available in the >> inner libc, that's for sure a bug we must fix), AT_EXECFN, or >> /proc/self/exe.  If we pick one of these for the auditor, we make it >> more difficult to make the appropriate choice. > > Apologies, but I don't understand the logic here. The main executable is easy to identify in la_objopen as `l_prev == NULL && lmid == LM_ID_BASE`, the same (effectively) is done in gdb [1]. Applications have dlinfo(dlopen(NULL)) to directly obtain the main executable's link_map. I fail to see how setting l_name to "" is superior to either of those options, especially given the downsides. > > I agree with Adhemerval. There is no portable way for an auditor to acquire the resolved path to the main executable, AT_EXECFN and /proc are Linux-specific and dladdr (currently) often crashes from the auditor. An l_name of "" means auditors *cannot* make the appropriate choice. 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. And it also helps for the case where execve() is called with bogus initial argument. > > [1] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/solib-svr4.c;hb=d3de0860104b8bb8d496527fbb042c3b4c5c82dc#l1230