[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 17 Aug 2022 17:30:58 -0400
From: James Y Knight <jyknight@...gle.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com, elvis@...edb.com
Subject: Re: [PATCH] ldso/dynlink: Protect LD_ env vars from getting
clobbered by apps
That issue was already fixed in 3.10. Currently, only PR_SET_MM_MAP and
PR_SET_MM_MAP_SIZE operations require CRIU support enabled, the others do
not.
If anyone sufficiently motivated would like to propose a patch to the
kernel to allow {ARG,ENV}_{START_END} operations by non-root users, that'd
be pretty awesome. Then maybe in another couple decades, programs can stop
using these awful hacks.
On Wed, Aug 17, 2022 at 3:28 PM Rich Felker <dalias@...c.org> wrote:
> On Wed, Aug 17, 2022 at 12:10:48PM -0400, James Y Knight wrote:
> > Sidenote: Linux does support a less awful way to change the kernel's view
> > of argv these days, using prctl(PR_SET_MM, PR_SET_MM_ARG_START (or _END),
> > addr, 0, 0). Sadly, it only allows root (CAP_SYS_RESOURCE) to use it. I'm
> > not sure why, perhaps that restriction could be relaxed for future
> > kernels...
> >
> > See
> >
> https://github.com/systemd/systemd/blob/87305b0fbfc0e40a948cf0a683bcf9d47b8a41a3/src/basic/process-util.c#L256
> > for an example of use (including ugly workaround for the API being silly
> > and setting START/END with separate syscalls, but requiring START <= END
> at
> > all times)
>
> Yes, unfortunately (at least last I checked) it's also only available
> if CRIU support was enabled in the kernel since that's the only thing
> its creators envisioned it being used for... *sigh*
>
> >
> > On Wed, Aug 17, 2022 at 6:05 AM Elvis Pranskevichus <elvis@...edb.com>
> > wrote:
> >
> > > There is no guarantee that the environment block will remain intact.
> > > For example, PostgreSQL clobbers argv/environ area to implement its
> > > "setproctitle" emulation on non-BSD [1], and there is a popular Python
> > > library inspired by it [2]. As a result, setting `LD_LIBRARY_PATH`
> > > or `LD_PRELOAD` has no effect on Postgres subprocesses when linking
> > > against musl.
> > >
> > > Protect against this by making a copies instead of storing the
> > > original pointers directly.
> > >
> > > (please CC me, I'm not subscribed to the list)
> > >
> > > ---
> > > ldso/dynlink.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/ldso/dynlink.c b/ldso/dynlink.c
> > > index cc677952..703342b8 100644
> > > --- a/ldso/dynlink.c
> > > +++ b/ldso/dynlink.c
> > > @@ -1756,8 +1756,8 @@ void __dls3(size_t *sp, size_t *auxv)
> > >
> > > /* Only trust user/env if kernel says we're not suid/sgid */
> > > if (!libc.secure) {
> > > - env_path = getenv("LD_LIBRARY_PATH");
> > > - env_preload = getenv("LD_PRELOAD");
> > > + env_path = strdup(getenv("LD_LIBRARY_PATH"));
> > > + env_preload = strdup(getenv("LD_PRELOAD"));
> > > }
> > >
> > > /* Activate error handler function */
> > >
> > >
> > >
> > >
> > >
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
