glibc feature request: LD_ETC_IGNORE - environment variable to ignore /etc/ld.so.preload configuration file on a per-application basis

glibc feature request: LD_ETC_IGNORE - environment variable to ignore /etc/ld.so.preload configuration file on a per-application basis
I’ve made a summary of all open issues:
Hardened Malloc
That did not go too well yet.
That still wouldn’t give us a way to disable hardened malloc on a per application basis without extraneous stderr error message?
( ERROR: ld.so: object ‘/usr/lib/libhardened_malloc.so/libhardened_malloc_kicksecure.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
)
adding hardened-malloc-disable
not appropriate as this would inject stderr output ERROR: ld.so: object ‘/usr/lib/libhardened_malloc.so/libhardened_malloc_kicksecure.so’ from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
during early boot process (swap-file-creator) and not appropriate to silence stderr either as this would hide legitimate error messages too.
Here is a new approach for disabling hardened malloc on a per-application basis without extraneous console stderr output.
Why hide folder /usr/lib/libhardened_malloc.so
from application if we can hide /etc/ld.so.preload
configuration file?
sudo touch /etc/empty
bwrap --dev-bind / / --ro-bind /etc/empty /etc/ld.so.preload man nano
That would be an ld-system-preload-disable
tool.
(But not a global ld-disable-tool
because it would not modify LD_PRELOAD
environment variable. We could invent such a tool easily too if needed.)
That would be good enough?
It would not be an hardened-malloc-disable
tool because other entries (unrelated user specific preloads) in /etc/ld.so.preload
configuration file would be excluded too. A hardened-malloc-disable
could copy /etc/ld.so.preload
to a (temporary?) file, use
str_replace /usr/lib/libhardened_malloc.so/libhardened_malloc_kicksecure.so "" /path/to/other-ld.so.preload-file
and then use brwap to point the application to that file instead.
Should could added to helper-scripts
package. (Previously my mistake directing hardened-malloc-disable
at usablity-misc
package.) Is an hardened-malloc-disable
tool worth the effort or is ld-system-preload-disable
tool sufficient?
Is it a security issue that users (non-root) can disable /etc/ld.so.preload
? Is that something only root should be able to configure?
Yes, that would be great. Verified with /proc/self/maps
that hardened_malloc is not loaded.
ld-system-preload-disable
should be sufficient for now.
No. An attacker can only disable it for new processes that they create which there isn’t any point in. They can’t disable it for already existing processes. E.g. a malicious site can’t just disable hardened_malloc for Firefox and exploit it.
Is there any reason to create a new file instead of:
bwrap --dev-bind / / --ro-bind /dev/null /etc/ld.so.preload man nano
?
I tried Chromium from Debian backports and still got the same error so the error could be from Debian’s patches or the backport isn’t a recent enough version.
I’ll look over the patches and see if I can find anything. Looking at these has also made me realize just how terrible the Debian Chromium package is (they disable important mitigations like CFI, automatic variable initialization, etc.)
I just tried the same version of Chromium as in the Debian repos but on a different distro (Arch) and the error wasn’t there. It’s most likely Debian’s patches.
madaidan via Whonix Forum:
Is there any reason to create a new file instead of:
bwrap --dev-bind / / --ro-bind /dev/null /etc/ld.so.preload man nano
?
While not tested by me yet, using /dev/null seems much better.
Will add the new wrapper soon and remove the old one (wrong package, my
mistake, and probably no need to reintroduce).
Implemented that.
There is one issue.
This fails if file /etc/ld.so.preload does not exists.
bwrap: Can’t create file at /etc/ld.so.preload: Permission denied
Can this be fixed at bwrap
level? Or must I make sure at packaging level that file /etc/ld.so.preload
always exists?
(That is for systems with hardened-malloc-kicksecure-enable not installed.)
Could you please report your chromium related findings to Debian? I guess replying again to
https://bugs.debian.org/971876 for the hardened malloc issue? (i.e. Debian patches are probably responsible for introducing the issue.)
And a separate ticket about CFI etc.?
Not really unless it’s run as root.
Uploaded to developers and testers repository just now.
Daniel has told me that this release may fix some of the issues we’ve been facing. Will test.
Edit: Doesn’t seem to fix anything.
I have discovered a way to disable the man
seccomp filter. You can set the MAN_DISABLE_SECCOMP=1
environment variable.
https://git.savannah.nongnu.org/cgit/man-db.git/tree/lib/sandbox.c#n142
The hardened-malloc package can simply create /etc/X11/Xsession.d/50hardened-malloc
with contents:
#!/bin/sh
## Copyright (C) 2012 - 2020 ENCRYPTED SUPPORT LP <adrelanos@riseup.net>
## See the file COPYING for copying conditions.
export MAN_DISABLE_SECCOMP=1
I doubt there will be any practical security disadvantages with this. Man pages aren’t exactly untrusted input and a seccomp filter is not a complete sandbox by itself anyway (e.g. it’s not like it can provide proper filesystem restrictions).
Awesome!
https://github.com/Whonix/hardened_malloc/blob/master/debian/50hardened-malloc
Much better solution than config-package-dev wrappers. Btw…
Fixed in man
upstream. Fix will probably arrive and can be removed in Debian bullseye
and above.
Not yet tested…
All untested… Another major issue. Breaks sshd
.
Also fixed upstream in sshd
, but Debian buster
version still has this issue. Killing sshd
on servers is a very high impact issue. Also probably fixed in Debian bullseye
. This speaks against installation by default before Debian bullseye
. Got any workaround for that?
That works for
Doesn’t work for:
sudo apt install --reinstall nano
)…because /etc/X11/Xsession.d
cannot set environment variables everywhere.
I don’t think Debian / Linux has any way to really set an environment variable globally everywhere?
No, I don’t think OpenSSH allows disabling the seccomp filter at runtime. There only appears to be compile-time options.
There’s /etc/environment
but no drop-in files.
It’s not global either. Wouldn’t work for APT or systemd units.
Maybe systemd’s DefaultEnvironment=
would work?
https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html
Maybe systemd’s
DefaultEnvironment=
would work?
Good find. Maybe we could use this for preloading hardened_malloc also?
Some unrelated but interesting settings for security are in that man page too:
CapabilityBoundingSet
NoNewPrivileges
SystemCallArchitectures
Maybe we could use this for preloading hardened_malloc also?
Not sure.
DefaultEnvironment=
is “not really global”. It’s “pretty good but not perfect”.
DefaultEnvironment=
sets environment variables it for all systemd units [1] [2], virtual consoles but not for graphical X sessions. I don’t know why yet. This may or may not be fault of systemd. The login manager or X might unset environment variables.
It can be viewed using:
systemctl show-environment
I don’t know yet a (full) list of exceptions where DefaultEnvironment=
is effectively, eventually ignored due to whatever cause.
However, DefaultEnvironment=
might be be good enough for MAN_DISABLE_SECCOMP=1
man
seccomp
workaround. Implementing now.
[1] To add more potential exceptions… Individual systemd units using Environment=
or EnvironmentFile=
may or may not change this. Untested.
[2] Good enough for our use case as long as no APT related systemd units do this.