From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 430C23857BB2; Thu, 23 Feb 2023 16:02:23 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 430C23857BB2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1677168143; bh=ElDqLoqnjzyULlfRZKlAECm4Vb7mdaUP+LAtB6VtvTo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=wwmFQmf/4jY5gUv1M7Gk9nAwh1XRzlv0fr8okxAp/Ev+z0G0m2KnvtJroNsip8c4B LHBzNYel9Jc+SJTv6p+/D/3A3qtQhBaV2ofSo3RMwjpCtWyx4MXy0M/L3tAej4H6U9 3nku2YZxBDx8h+vcnXfXKs/jOQ1a+T8oJ4WWbphg= From: "janderson at rice dot edu" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/30127] [rfe]: enable ld audit at run-time Date: Thu, 23 Feb 2023 16:02:22 +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: janderson at rice dot edu 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=3D30127 --- Comment #21 from Jonathon Anderson --- (In reply to Stas Sergeev from comment #19) > (In reply to Jonathon Anderson from comment #18) > > void la_preinit(uintptr_t* cookie) { > > void* h =3D dlmopen(LM_ID_BASE, NULL, RTLD_LAZY | RTLD_NOLOAD); > > void (*hook)() =3D dlsym(h, "_auditor_hook"); > > hook(...); > > } >=20 > Well, yes, auditor_hook is a viable > solution perhaps in some cases. Though > in my case the auditor is brought in with > a solib plugin, not with the main application. > And currently DT_AUDIT is not supported for > solibs, see #30134. > And even if #30134 is fixed, will you be > able to resolve the auditor hook with > LM_ID_BASE if it is in an RTLD_LOCAL solib > rather than in a main executable? > I think not, so the scope of your solution > is quite limited. Assuming you can get an auditor into the process (LD_AUDIT env var), if you= can identify the solib from it's loaded path, you can (recursively) load the so= lib during the la_objopen callback and access the auditor hook that way: unsigned int la_objopen(struct link_map* m, Lmid_t lmid, uintptr_t* cookie)= { if(m->l_name /* ... is the target solib */) { void* h =3D dlmopen(lmid, m->l_name, RTLD_LAZY | RTLD_NOLOAD); void (*hook)() =3D dlsym(h, "_auditor_hook"); hook(); } return 0; } Like most of LD_AUDIT, this isn't a well-tested code path, so be careful and expect some bugs. For example, don't try this during the later la_activity(LA_ACT_CONSISTENT) callback, you'll get a glorious crash. :) >=20 > > I'm a bit confused how the proposed interface would provide a better (or > > alternate) solution to the problem. >=20 > By doing > void *auditor_handle =3D dlload_audit_module("my_module", 0); > void (*auditor_cb)(void) =3D dlsym(auditor_handle, > "auditor_control_interface"); > Just as simple as that. :) >=20 > > Echoing a few of Florian's concerns, if > > you load an auditor after the application has been running for a time, = you > > run a large risk of being passed an unrecognizable cookie (since the > > la_objopen callbacks are fired before the auditor is loaded). >=20 > Good point, so I'll adjust the patch to > not call the auditor for the lib for which > he missed the initial cookie... which doesn't > look simple. :) > Oh, will think... > Thanks! This still doesn't solve the issue. Expanding a bit: say you load dlload_audit_module("my_auditor"), then dlopen("libmylib.so") and libmylib.= so binds malloc from libc.so. my_auditor gets an la_objopen call for libmylib.= so but not libc.so. What do you do about the la_symbind callback?: - If you send an la_symbind to my_auditor, the defcook will be an unrecognized cookie. - If you skip the call, my_auditor won't be able to intercept malloc (and= all other libc functions).=20 - If you NULL the defcook, my_auditor won't be able to wrap malloc etc. s= ince it can't (reliably) get the "original" function it would bind to. And it's = an API break, so you need to bump LAV_CURRENT. There are use cases that don't need la_symbind, e.g. an auditor that records used libraries or denies access to libraries outside of a "whitelist." But I also think most (if not all) of those use cases would operate far better as= a global auditor (LD_AUDIT) rather than one dynamically loaded late in the application. Especially for any security-related purpose. What is your proposed auditor supposed to do? --=20 You are receiving this mail because: You are on the CC list for the bug.=