public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "janderson at rice dot edu" <sourceware-bugzilla@sourceware.org> 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 [thread overview] Message-ID: <bug-30127-131-Ff7RGxIiFo@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-30127-131@http.sourceware.org/bugzilla/> https://sourceware.org/bugzilla/show_bug.cgi?id=30127 --- Comment #21 from Jonathon Anderson <janderson at rice dot edu> --- (In reply to Stas Sergeev from comment #19) > (In reply to Jonathon Anderson from comment #18) > > void la_preinit(uintptr_t* cookie) { > > void* h = dlmopen(LM_ID_BASE, NULL, RTLD_LAZY | RTLD_NOLOAD); > > void (*hook)() = dlsym(h, "_auditor_hook"); > > hook(...); > > } > > 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 solib 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 = dlmopen(lmid, m->l_name, RTLD_LAZY | RTLD_NOLOAD); void (*hook)() = 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. :) > > > I'm a bit confused how the proposed interface would provide a better (or > > alternate) solution to the problem. > > By doing > void *auditor_handle = dlload_audit_module("my_module", 0); > void (*auditor_cb)(void) = dlsym(auditor_handle, > "auditor_control_interface"); > Just as simple as that. :) > > > 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). > > 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). - If you NULL the defcook, my_auditor won't be able to wrap malloc etc. since 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? -- You are receiving this mail because: You are on the CC list for the bug.
next prev parent reply other threads:[~2023-02-23 16:02 UTC|newest] Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-02-15 8:23 [Bug dynamic-link/30127] New: " stsp at users dot sourceforge.net 2023-02-16 18:42 ` [Bug dynamic-link/30127] " fweimer at redhat dot com 2023-02-17 2:54 ` stsp at users dot sourceforge.net 2023-02-17 7:17 ` stsp at users dot sourceforge.net 2023-02-17 8:08 ` fweimer at redhat dot com 2023-02-17 8:38 ` stsp at users dot sourceforge.net 2023-02-17 8:56 ` fweimer at redhat dot com 2023-02-17 9:32 ` stsp at users dot sourceforge.net 2023-02-17 9:38 ` stsp at users dot sourceforge.net 2023-02-17 9:44 ` stsp at users dot sourceforge.net 2023-02-17 10:23 ` fweimer at redhat dot com 2023-02-17 10:59 ` stsp at users dot sourceforge.net 2023-02-17 12:46 ` fweimer at redhat dot com 2023-02-17 13:43 ` schwab@linux-m68k.org 2023-02-17 13:55 ` stsp at users dot sourceforge.net 2023-02-17 13:57 ` stsp at users dot sourceforge.net 2023-02-20 8:33 ` fweimer at redhat dot com 2023-02-21 15:39 ` stsp at users dot sourceforge.net 2023-02-21 19:43 ` janderson at rice dot edu 2023-02-21 20:09 ` stsp at users dot sourceforge.net 2023-02-22 16:46 ` stsp at users dot sourceforge.net 2023-02-23 16:02 ` janderson at rice dot edu [this message] 2023-02-23 16:35 ` stsp at users dot sourceforge.net 2023-02-24 18:02 ` stsp at users dot sourceforge.net 2023-02-25 16:57 ` stsp at users dot sourceforge.net 2023-02-25 18:49 ` carlos at redhat dot com 2023-02-25 19:00 ` stsp at users dot sourceforge.net 2023-02-26 16:54 ` janderson at rice dot edu 2023-02-26 17:22 ` stsp at users dot sourceforge.net 2023-02-26 19:22 ` stsp at users dot sourceforge.net 2023-03-02 14:39 ` stsp at users dot sourceforge.net 2023-03-02 16:13 ` janderson at rice dot edu 2023-03-02 19:56 ` stsp at users dot sourceforge.net 2023-03-03 6:20 ` janderson at rice dot edu 2023-03-03 12:36 ` stsp at users dot sourceforge.net 2023-03-04 11:33 ` stsp at users dot sourceforge.net 2023-03-06 9:12 ` janderson at rice dot edu 2023-03-06 10:09 ` stsp at users dot sourceforge.net 2023-03-06 10:56 ` stsp at users dot sourceforge.net 2023-03-07 8:54 ` janderson at rice dot edu 2023-03-07 16:50 ` stsp at users dot sourceforge.net 2023-03-12 8:42 ` stsp at users dot sourceforge.net 2023-03-13 9:22 ` janderson at rice dot edu 2023-03-13 9:41 ` janderson at rice dot edu 2023-03-13 10:01 ` stsp at users dot sourceforge.net 2023-03-13 10:46 ` stsp at users dot sourceforge.net 2023-03-13 11:17 ` stsp at users dot sourceforge.net 2023-03-13 20:26 ` stsp at users dot sourceforge.net 2023-03-14 15:11 ` stsp at users dot sourceforge.net 2023-03-15 5:34 ` janderson at rice dot edu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-30127-131-Ff7RGxIiFo@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).