Where should this be enabled? A new package - hardened-malloc-enable?
1 Like
That… Is a good question… I was thinking about how to best enable this.
Only option seems to be this:
Hardened Malloc
I.e. modify /etc/ld.so.preload. Would be a bit troublesome because there is no drop-in folder at time of writing. [1] Was thinking about writing to that file from a postinst script (check if the so exists) and removing it in the prerm script. Protected by a state file write to /etc/ld.so.preload just once to allow the user to disable this.
Considered doing this in the hardened-malloc package but your question made me think that this again would destroy the “unmodified hardened-malloc package public service Debian package” since enabling hardened-malloc-kicksecure by default was probably not what the user intended / expected.
I would like to avoid the overhead of having a dedicated pacakge only doing hardened-malloc-enable.
Perhaps easiest would be to abolish the “public service” of a plain Debian unmodified hardened-malloc package and calling it a Kicksecure fork since we change compile time options and enable that one by default? Probably a small thing because I guess very few use such a geeky “public service”.
[1] related feature request: /etc/ld.so.preload.d drop-in configuration folder support
1 Like
Merged.
Installation path was actually wrong. Found a fix.
Quote dh_install(1) — debhelper — Debian testing — Debian Manpages
dh_install cannot rename files or directories, it can only install them with the names they already have into wherever you want in the package build tree.
However, renaming can be achieved by using dh-exec with compatibility level 9 or later. An example debian/ package .install file using dh-exec could look like:
#!/usr/bin/dh-exec debian/default.conf => /etc/my-package/start.conf
1 Like
What do you think about adding it to security-misc?
I don’t think we should do that. A plain hardened_malloc package can be quite useful.
1 Like
Possible somehow but I don’t see yet how to do that in a proper, clean way packaging wise.
That would be an option if hardened-malloc wasn’t platform specific but it is. Adding a dependency to security-misc would make security-misc needlessly platform specific. Well, there is dummy-dependency but then security-misc would depend on anon-meta-package to provide dummy-dependency to become platform independent or security-misc would have to duplicate dummy-dependency functionality.
hardened-malloc package can ship code for enabling hardened-malloc-kicksecure code in its /debian folder and only run it if running inside Kicksecure or Whonix. That alone however would be prone to not being executed in some situations such as “apt get install whonix” or “apt get install kicksecure” (installation from repository). I.e. in case hardened-malloc gets installed before kicksecure-base-files or whonix-base-files package. Therefore a dpkg trigger in hardened-malloc package is required to make sure it is enabled by default once the system becomes Kicksecure or Whonix. Also doable, seems a better solution, but also way more complex than deprecating “unmodified hardened-malloc Debian package public service”.
1 Like
How is it platform-specific? hardened_malloc can be used on any Linux distro. Are you referring to the Debian packaging? How’s that any different from security-misc’s current dependencies or security-misc itself?
Would that be worth it? A separate package for it seems much neater than that.
1 Like
Should set CONFIG_NATIVE=false for libhardened_malloc.so_kicksecure too, no? Will add now.
platform-specific, 64 bit only. Mentioned here:
glibc integration · Issue #102 · GrapheneOS/hardened_malloc · GitHub
This I don’t know but probably yes.
By platform support I mean other platforms such as i386. Which is actually a bad example since one could say “i386 is obsolete” but the old example I have handy where I can show a reference that it is confirmed unsupported. Also less easily dismissed platforms such as AArch32 are therefore probably also unsupported.
Debian supports a lot architectures, various hardware, including non-Linux.
https://wiki.debian.org/SupportedArchitectures
security-misc for now is just config files and scripts which should work anywhere. Compiled code specifically something so specialized like hardened-malloc cannot be expected to have same platform support. Also after reading above ticket, I don’t think upstream would be interested to fix platform specific compilation issues if no pull request was provided (if that is even technically possible to fix on that platform).
I haven’t checked but I’d assume that all Depends: of security-misc are available for all Debian supported platforms as ready made packages as usual.
1 Like
I can add generation of hardened-malloc-kicksecure(-enable) to the hardend_malloc git repository. That way it won’t have the overhead of yet another git repository. Then Kicksecure specific files for enabling /usr/lib/libhardened_malloc.so/libhardened_malloc.so in /etc/ld.so.preload could be added there.
- Whonix-Workstation issue:
(lkrg [not sure if related, probably not] +) hardened malloc kicksecure results in kloak systemd unit failing. It’s an apparmor and systemd seccomp isssue.
Could you please make this compatible apparmor and systemd seccomp wise Whonix wide? (I mean, any systemd unit files / apparmor profiles that might be related. hardened-malloc folder should probably be added to apparmor-profile-dist.
- Debian / Kicksecure Host specific:
Added /usr/lib/libhardened_malloc.so/libhardened_malloc_kicksecure.so to /etc/ld.so.preload without reboot, started another terminal tab and then run virtualbox from there.
- Host / Kicksecure specific:
chromium
fatal allocator error: invalid uninitialized allocator usage
Received signal 6
#0 0x59425ffb3529 (/usr/lib/chromium/chromium+0x51f9528)
#1 0x59425ff11253 (/usr/lib/chromium/chromium+0x5157252)
#2 0x59425ffb30b1 (/usr/lib/chromium/chromium+0x51f90b0)
#3 0x7b3117dfd730 (/usr/lib/x86_64-linux-gnu/libpthread-2.28.so+0x1272f)
#4 0x7b3111cbe7bb gsignal
#5 0x7b3111ca9535 abort
#6 0x7b3117e32076 (/usr/lib/libhardened_malloc.so/libhardened_malloc_kicksecure.so+0x7075)
#7 0x7b3117e311bf malloc_usable_size
#8 0x594260da4ed9 (/usr/lib/chromium/chromium+0x5feaed8)
#9 0x594260e6be4f (/usr/lib/chromium/chromium+0x60b1e4e)
#10 0x594260db5d40 (/usr/lib/chromium/chromium+0x5ffbd3f)
#11 0x594260d9c6ea (/usr/lib/chromium/chromium+0x5fe26e9)
#12 0x594260d971a6 (/usr/lib/chromium/chromium+0x5fdd1a5)
#13 0x594260d96f02 (/usr/lib/chromium/chromium+0x5fdcf01)
#14 0x594261511d9f (/usr/lib/chromium/chromium+0x6757d9e)
#15 0x594261513352 (/usr/lib/chromium/chromium+0x6759351)
#16 0x5942615131ee (/usr/lib/chromium/chromium+0x67591ed)
#17 0x59425ff5fa82 (/usr/lib/chromium/chromium+0x51a5a81)
#18 0x59425ff75662 (/usr/lib/chromium/chromium+0x51bb661)
#19 0x59425ff750a6 (/usr/lib/chromium/chromium+0x51bb0a5)
#20 0x59425ffc29ab (/usr/lib/chromium/chromium+0x52089aa)
#21 0x59425ff74c32 (/usr/lib/chromium/chromium+0x51bac31)
#22 0x59425ff81e76 (/usr/lib/chromium/chromium+0x51c7e75)
#23 0x59425ff81b91 (/usr/lib/chromium/chromium+0x51c7b90)
#24 0x59425ffc318e (/usr/lib/chromium/chromium+0x520918d)
#25 0x7b3117df2fa3 start_thread
#26 0x7b3111d804cf clone
r8: 0000000000000000 r9: 00007b30ca7fa9b0 r10: 0000000000000008 r11: 0000000000000246
r12: 00007b30ca7faec8 r13: 0000000000000000 r14: 0000000000000028 r15: 0000594264ad5910
di: 0000000000000002 si: 00007b30ca7fa9b0 bp: 00007b30ca7fac60 bx: 0000000000000006
dx: 0000000000000000 ax: 0000000000000000 cx: 00007b3111cbe7bb sp: 00007b30ca7fa9b0
ip: 00007b3111cbe7bb efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000
trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.
Fixable?
1 Like
The host hardened malloc was disabled. Only Whonix VM hardened malloc kicksecure enabled (+lkrg). It results in VirtualBox host software VM crash.
A critical error has occurred while running the virtual machine and the machine execution should be stopped.
For help, please see the Community section on https://www.virtualbox.org or your support contract. Please provide the contents of the log file VBox.log, which you can find in the virtual machine log directory, as well as a description of what you were doing when this error happened. Note that you can also access the above file by selecting Show Log from the Machine menu of the main VirtualBox window.
Press OK to power off the machine.
1 Like
Enabling /usr/lib/libhardened_malloc.so/libhardened_malloc_kicksecure.so by default should now be trivial thanks to hardened-malloc-kicksecure-enable package.
Once ready to enable by default, this can be added as a dependency to anon-meta-packages/debian/control at master · Whonix/anon-meta-packages · GitHub
Change all occurrences of:
hardened-malloc | dummy-dependency,
To:
hardened-malloc | dummy-dependency,
hardened-malloc-kicksecure-enable | dummy-dependency,
2 Likes
If any future seccomp issues occur, compare the filter with GitHub - GrapheneOS/hardened_malloc: Hardened allocator designed for modern systems. It has integration into Android's Bionic libc and can be used externally with musl and glibc as a dynamic library for use on other Linux-based platforms. It will gain more portability / integration over time.
A common issue is getrandom.
It already is: https://github.com/Whonix/apparmor-profile-dist/blob/master/etc/apparmor.d/abstractions/base.anondist#L68
Could be a memory corruption vulnerability in Chromium uncovered by hardened_malloc. I’ll investigate more. A solution for now is:
bwrap --dev-bind / / --tmpfs /usr/lib/libhardened_malloc.so chromium
Make sure to enable unprivileged user namespaces or disable the browser sandbox though as bubblewrap sets no_new_privs which disables the setuid sandbox.
Could also be another vulnerability in Virtualbox (wouldn’t be too surprised considering Oracle’s security practices).
Make sure to also create /etc/sysctl.d/30_hardened-malloc-kicksecure.conf with:
vm.max_map_count=524240
2 Likes
I can’t seem to reproduce this. What exactly did you do to cause this? Please also post the contents of VBox.log.
1 Like
Also, man still crashes but newer releases have fixed its issue with hardened_malloc (the lack of getrandom in the seccomp filter). When do you think it will get to Debian?
1 Like
madaidan via Whonix Forum:
Also,
manstill crashes but newer releases have fixed its issue with hardened_malloc (the lack of getrandom in the seccomp filter). When do you think it will get to Debian?
I don’t know. Most likely not before buster+1 (bullseye).
Btw, I wouldn’t consider broken man as a blocker for enabling this by
default. Using manpages.debian.org (or similar) online is good enough.
Also is there some way to disable hardened-malloc-kicksecure on a per
application basis?
1 Like
Yes.
We could probably create a script to handle this easily.
2 Likes
Well, using brwap to get disable of hardened-malloc-kicksecure per application isn’t a great way to disable it. Was hoping for something less complex. Is there?
Anyhow, if you like, please add a wrapper script to let’s say usabiltiy-misc package? /usr/bin/hardened-malloc-disable (covering both, upstream and kicksecure version)?
1 Like
I’m not aware of any (apart from other namespacing programs like unshare but they’re essentially the same thing).
Should that just be:
bwrap --dev-bind / / --tmpfs /usr/lib/libhardened_malloc.so "${@}"
or something more complex like using a config file and application wrappers?
1 Like
Just that is good enough for now. A stopgap we can tell users “use that wrapper” to work around issues. Running hardened-malloc-disable man ls would not be that bad.
(Prepending wrappers automatically, the stackable wrappers feature required for sandboxed-app-launcher etc. is way more complex and can be done at any later point. Actually these stackable wrappers could run programs such as hardened-malloc-disable to have it all nicely separated, 1 tool, 1 purpose.)
2 Likes
2 Likes