Hardened Malloc - Hardened Memory Allocator

Not really unless it’s run as root.

1 Like

Uploaded to developers and testers repository just now.

2 Likes
1 Like

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.

1 Like

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).

1 Like

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?

1 Like

That works for

  • users of X.

Doesn’t work for:

  • users not using X such as login in a virtual console.
  • apt (to test: sudo apt install --reinstall nano)
  • services executed through systemd.

…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?

1 Like

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

1 Like

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

1 Like

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”
0

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

lexgrog: zcat: Bad system call (core dumped)

1

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