Hardened Malloc - Hardened Memory Allocator

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.

1 Like

lintian is getting confused.

lintian  --suppress-tags testsuite-autopkgtest-missing --quiet --pedantic --info --display-info  "/home/user/whonix_binary/genmkfile-packages-result/helper-scripts_8.5-1_amd64.changes"

W: helper-scripts: manpage-has-bad-whatis-entry usr/share/man/man1/str_replace.1.gz

This breaks the build process. Probably happening due to lintian's internal use of lexgrog.

env -i MAN_DISABLE_SECCOMP=1 lexgrog /usr/share/man/man1/nano.1.gz

/usr/share/man/man1/nano.1.gz: “nano - Nano’s ANOther editor, an enhanced free Pico clone”

env -i MAN_DISABLE_SECCOMP= lexgrog /usr/share/man/man1/nano.1.gz

lexgrog: zcat: Bad system call (core dumped)


I guess this is happening because lintian implicitly unsets MAN_DISABLE_SECCOMP environment variable. (It only sets LC_ALL.)

        delete local $ENV{$_}
          for grep { $_ ne 'PATH' && $_ ne 'TMPDIR' } keys %ENV;
        local $ENV{LC_ALL} = 'C.UTF-8';

        my @command = ('lexgrog', $file->unpacked_path);

Btw MAN_DISABLE_SECCOMP=0 does not really work to re-enable man seccomp for tesging purposes but MAN_DISABLE_SECCOMP= does.

Should be fixed by this workaround.

openssh-server (sshd) is broken indeed in Debian buster in combination with hardened-malloc-kicksecure. Tested just now.

A potential workaround would be a systemd unit file drop in prepending ld-system-preload-disable in for ExecStart= etc. in front of sshd. Thoughts?

1 Like

OpenSSH feature request: test compatibility with hardened memory allocator Hardened Malloc

1 Like

It may work but sshd sets up its own sandbox that ld-system-preload-disable may conflict with.

1 Like

VirtualBox bug report: VirtualBox crashes with hardened memory allocator Hardened Malloc on the host

1 Like

Added: https://github.com/openssh/openssh-portable/commit/b744914fcb76d70761f1b667de95841b3fc80a56

1 Like
1 Like

Now in Whonix developers repository.

1 Like

Wondering if hardend malloc can be combined with flatpak.

On the host:

cat /proc/$$/maps | grep malloc

[…] /usr/lib/libhardened_malloc.so/libhardened_malloc_kicksecure.so

Run a shell for debugging purposes inside flatpak.

flatpak run --command=bash org.chromium.Chromium

See if hardend malloc Kcksecure is loaded.

cat /proc/$$/maps | grep malloc

No, it’s not.

Trying to ld preload hardened malloc Kicksecure using environment variable inside flatpak.

flatpak run --env=LD_PRELOAD=/usr/lib/libhardened_malloc.so/libhardened_malloc_kicksecure.so org.chromium.Chromium

ERROR: ld.so: object ‘/usr/lib/libhardened_malloc.so/libhardened_malloc_kicksecure.so’ from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

Any ideas?

Not sure that makes sense for Chromium. Which allocator is more secure, Chromium’s built-in or Hardened Malloc (Kicksecure)?

But even if it doesn’t make sense for Chromium, would be useful to know generally for other applications from flatpak.

The file /usr/lib/libhardened_malloc.so/libhardened_malloc_kicksecure.so is likely not available from within the Flatpak sandbox.

hardened_malloc is more secure but you can’t just switch allocators with LD_PRELOAD since Chromium uses PartitionAlloc internally anyway, similar to Firefox with mozjemalloc.

1 Like

telegram desktop failing with Hardened Malloc Kicksecure (on Qubes Debian template):

fatal allocator error: invalid free

1 Like

I can’t reproduce this. At exactly which point does this happen? Immediately upon start of the app or when doing something (e.g. logging in, clicking on a chat, etc.)?

1 Like

Actually, when preloading hardened_malloc with Telegram on my host, I got a different error:

fatal allocator error: sized deallocation mismatch (large)

Edit: using a newer hardened_malloc seems to have fixed that.

1 Like
[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]