From: Jonathon Anderson <janderson@rice.edu>
To: Florian Weimer <fweimer@redhat.com>
Cc: libc-alpha@sourceware.org, Carlos O'Donell <carlos@redhat.com>
Subject: Re: RFC: Auditor access to program headers
Date: Thu, 17 Mar 2022 15:16:11 -0500 [thread overview]
Message-ID: <ba277e95-8b3f-2046-0cfb-ab46d1d9804c@rice.edu> (raw)
In-Reply-To: <87v8wcoc9z.fsf@oldenburg.str.redhat.com>
On 3/17/22 09:59, Florian Weimer wrote:
>> We propose two changes to support this use case:
>> - Addition of a new dlinfo request that fills a dl_phdr_info (or
>> similar) structure identically to how dl_iterate_phdr would. This
>> would enable access to a load module's program headers without use of
>> dl_iterate_phdr.
> The existing dlinfo requests are problematic (origin and search path
> information access suffers from buffer overflows), and these
> type-polymorphic dispatchers are never great. At least for program
> header lookup, it's possible to detect the unsupported request even
> though the current implementation does not report any errors in that
> case (the dlinfo caller needs to write a null pointer and check if it
> has been overwritten). So it looks a feasible short-term solution.
The current implementation does error on unsupported requests, and
AFAICT has since the initial implementation in 2003:
switch (args->request)
{
case RTLD_DI_CONFIGADDR:
default:
_dl_signal_error (0, NULL, NULL, N_("unsupported dlinfo
request"));
break;
Adding a new dlinfo request should work well enough for our purposes,
we'll keep a runtime fallback in case the request isn't supported.
For my own curiosity, what would you consider for a longer-term solution?
>> - A fix for the bug that causes dl* functions to crash in early
>> auditor notifications (one of our Tier 2 issues). This is required to
>> allow use of dlinfo within an auditor. Fixing this involves adjusting
>> rtld_active to return true during auditor notifications in dl_main.
> Almost all rtld_active calls can go away in glibc 2.34 because
> GLRO (dl_dlfcn_hook) is now in read-only memory. That change isn't
> quite backportable because throughly breaks static dlopen. But
> rtld_active could simply check some other _rtld_global_ro field
> in earlier glibc version.
Great! We'll be happy to test when it's available.
>> For additional clarity, it would also be helpful to have either:
>> - documentation that a link_map* is in fact a dlopen handle and thus
>> can be passed to any dl* function in current and future versions of
>> Glibc, or
> I think we can promise that every link map pointer provided by glibc can
> be used as a dlopen handle (during its life-time).
I believe this direction is the only one missing,
dlinfo(RTLD_DI_LINKMAP) exists for the other direction.
> The other direction
> (every handle returned by dlopen is a link map) might be more
> complicated. But perhaps we can at least commit to providing the public
> link map fields (as seen in the installed <link.h>).
>
>> - the prototype of la_objopen altered to take a void* dlopen handle
>> instead of a link_map* (which AFAIK currently has no or minimal ABI
>> impact).
> It's a source-incompatible change, though, because we declare la_objopen
> in <link.h>. So perhaps we can avoid it.
It's source-incompatible, though IMHO it's an easy configure test and a
very minor source change. If Glibc can't commit to keeping link_map*
usable as a dlopen handle (eg. for possible future security concerns),
this prevents the possibility that auditors could get "locked out" of
the dl* functions.
Thanks,
-Jonathon
next prev parent reply other threads:[~2022-03-17 20:16 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-16 18:25 Jonathon Anderson
2022-03-17 14:59 ` Florian Weimer
2022-03-17 20:16 ` Jonathon Anderson [this message]
2022-04-20 18:57 ` Florian Weimer
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=ba277e95-8b3f-2046-0cfb-ab46d1d9804c@rice.edu \
--to=janderson@rice.edu \
--cc=carlos@redhat.com \
--cc=fweimer@redhat.com \
--cc=libc-alpha@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: link
Be 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).