From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3EFCF384DD13; Mon, 20 Feb 2023 12:56:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3EFCF384DD13 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1676897812; bh=yruttZ+rb0zCit2jW2Yz1pjhkVpQcu7yX5l4mmPH58E=; h=From:To:Subject:Date:In-Reply-To:References:From; b=MdnpqJKjcqxtAYbfLF+yaU00BsDPkuhyZpbfmgmIxrBd5LKAsVvI1OyEpCdKjWXX1 +SCwJfxrhKZpnJkDuGCT9YwdrTLCqIwDav2+4MBNX9YePeVoCmHc3AXtUpDsxngqsH Btovbgd9YRcEsL56PdbuqCVLcVFJhlmGZld32uHs= From: "stsp at users dot sourceforge.net" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/30134] DT_AUDIT is ignored for dlopen()ed solib Date: Mon, 20 Feb 2023 12:56:51 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: 2.38 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: stsp at users dot sourceforge.net X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30134 --- Comment #7 from Stas Sergeev --- (In reply to Florian Weimer from comment #6) > If the auditor cannot intercept libc.so.6 calls because it is already > loaded, then it can even use the main libc.so.6, and no fully separate > namespace is needed at all. Certainly I don't know the implications, but in all projects where I needed to intercept the glibc calls I was using LD_PRELOAD (or the more advanced techniques like dlmopen() the libc into another namespace and intercept it there), but not LD_AUDIT. I've yet to understand is there something special in those complex pltenter/pltexit call-backs that you can't do by some other means, and are there many/any users of them? But having audit modules in the main namespace would help me a lot. Also wrt security hardening you mentioned, I wonder if such a measure (making audit list R/O) was applied exactly because of those pltenter/pltexit call-backs, that looks like the good target for code injection? If you had some subclass of "simple" auditors that only assist the dlopen() functionality, then would you still mark the list of such "simple" auditors read-only? Maybe we need the subclass of "simple" or "safe" auditors that would be allowed to load at run-time? Is there any write-up about the objectives and the desired functionality of that auditing frame-work, or was it evolving chaotically and eventually became a potential security risk? --=20 You are receiving this mail because: You are on the CC list for the bug.=