On Thu, Apr 8, 2021 at 9:57 PM Laurent Bercot <ska-skaw...@skarnet.org> wrote:
>   My toolchain also creates E stack binaries by default, no matter
> whether they're static or dynamic. It may be that my build of musl is
> bad.

That's unexpected.

>   I am not interested enough in the details of what happens at the ld
> level to try and figure out if there's *something* that causes it to
> mark E stack when it should not; it requires spending much more
> quality time with binutils than I am comfortable with. All I know is
> that none of the object files in my software needs E stack, and
> bullying ld into doing the right thing works, so I'm content with that
> solution.

Fair enough. That's totally fine for self-contained packages in which
you control the build parameters from end-to-end. This may become an
issue with skarnet libraries, such as utmps, that are used with other,
non-skarnet packages. Libutmps pulls in libskarnet and libskarnet
'pollutes' the other packages by making their stack executable.

I'm currently going through the process of linking some packages (e.g.
coreutils, util-linux, and the like) with libutmps, and now the
executables that call libutmps have their stack executable. I can deal
with it on my own by tweaking the LDFLAGS (-noexecstack) of those
packages, it's not too much of an issue for me.

But let's take Alpine Linux for example. I see that they now link
coreutils, and probably other packages I didn't check, with libutmps
and libskarnet. I don't know if they're affected by the same GNU_STACK
weirdness in skalibs, or if they scan their distribution binaries for
executable stacks, but they may be shipping a bunch of
innocuous-looking binaries that have an executable stack and may be
vulnerable as a result.

So IMHO it may be worthwhile spending some time at some point to
figure out what's going on and eventually make it not happen anymore.
Just my 2 cents.

Reply via email to