Re: [PATCH] Deny preload of files on NOEXEC mounts

[Jordan Abrahams via Libc-alpha <libc-alpha@sourceware.org>]

Hi Florian,

> There have been public discussions about such bugs before, not sure why
> you are restricting it.

I apologise. We can add any interested individuals to view the bug
thread (including you! Just let me know). However it's not in my
ability to make that thread public. Our security team originally
wished access to it to be restricted, and I'm obligated to abide by
that. I assume it's restricted because it has an example program which
bypasses noexec on ChromeOS devices, and Google doesn't want to risk
anything. I _can_ forward a request along to make it public, but I'm
afraid it's not my decision or in my power to do so.

> I expect that it will always be possible to take over the dynamic loader
> until we are more restrictive when it comes to use of MAP_FIXED in the
> loader, probably by using MAP_FIXED_NOREPLACE.  The challenge is to make
> the change so conservative that existing (slightly broken, or ia64)
> binaries are not impacted.

Given this, what are our options on getting dynamic loader attack
preventions upstream? For example, we don't have ia64 testing
ourselves, so we can't verify no impact even if we attempted to patch
the loader on our side.

We'd obviously like to have a more permanent upstream fix. O_NEEDEXEC
/ O_MAYEXEC seems like a fine long term solution in the kernel, and
we're trying to weigh the benefits of that versus maintaining this
glibc noexec patch locally. We don't know how long that would take
however, and our toolchain team certainly doesn't have the needed
expertise or cycles at this time. Plus we'd still also need an interim
solution while that is being worked on.

Thanks,
Jordan