[PATCH] Deny preload of files on NOEXEC mounts
Adhemerval Zanella
adhemerval.zanella@linaro.org
Fri Jul 23 23:59:06 GMT 2021
On 23/07/2021 18:27, Alexander Monakov wrote:
> On Fri, 23 Jul 2021, Adhemerval Zanella via Libc-alpha wrote:
>
>>
>>
>> $ mount | grep loopfs
>> /dev/loop0 on /home/azanella/loopfs type ext4 (rw,*noexec*,relatime,seclabel)
>> $ LD_PRELOAD=loopfs/libpreload.so ./test
>> ERROR: ld.so: object 'loopfs/libpreload.so' from LD_PRELOAD cannot be preloaded: ignored.
>> $ strace env LD_PRELOAD=loopfs/libpreload.so ./test
>> [...]
>> mmap(NULL, 2101304, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = -1 EPERM (Operation not permitted)
>> [...]
>>
>> I haven't tested a vanilla kernel yet.
>
> Vanilla kernel also does that, but I think you might be missing Jordan's point:
> this is not about refusing mmap from a noexec mount, this is a counter-measure
> against specially crafted ELF files taking over the dynamic loader even before
> it attempts a PROT_EXEC mmap, as demonstrated in glibc bug #21718:
> https://sourceware.org/bugzilla/show_bug.cgi?id=21718
>
> Alexander
>
Yes I am fully aware of that, but this is not what was the idea for the loader
laid out some years ago [1]. So maybe we should discuss again the design goal
and reevaluate some ideas. For instance, should we discuss to remove the multiple
features that are really a security hazards that we still support due compatibility?
What about somewhat useful features that contains multiple issue and possible
security issue like rtld-audit?
I tend to agree with Siddhesh, but at same time trying to parse ill-formed ELF
files are not easy tasks and might clash with current idea of a somewhat simple
and fast loader. We already ave multiple layers or security and filtering in
current modern OS, will adding another complexity on the loader really pay
off?
If we really want to focus on loader hardening, I think we really should use
Carlos's approach along with the idea of starting *deprecate* and remove some
features, even if it will result in incompatibilities (yes, some may frown
upon it, but it past time to really start to stop support things like
exec-stack, text-rels, and ldd.bash.in).
[1] https://sourceware.org/pipermail/libc-alpha/2015-July/062464.html
More information about the Libc-alpha
mailing list