This is now in Whonix testers repository.
Tested this by globally preloading it and there are a few issues (likely not with hardened_malloc itself though):
- It’s quite slow
- The mouse is a bit janky
- Xorg bugs out but then fixes itself
- The Tor Browser refuses to start
I still think we should enable this globally by default though. Just with a few exceptions + reporting any bugs uncovered upstream. Or, alternatively, we can try disabling a few options and see if it fixes anything.
Even with all of those options disabled, it’s still pretty secure.
I tried the leaner configuration example and literally all issues are fixed.
make \ CONFIG_WRITE_AFTER_FREE_CHECK=false \ CONFIG_SLOT_RANDOMIZE=false \ CONFIG_SLAB_QUARANTINE_RANDOM_LENGTH=0 \ CONFIG_SLAB_QUARANTINE_QUEUE_LENGTH=0 \ CONFIG_GUARD_SLABS_INTERVAL=8
I don’t even see much of a performance loss anymore. Can you test this also?
https://www.whonix.org/wiki/Hardened_Malloc is a Debian package for “public service” for lack of better term. Changing compile time options would be weird because then it would be a fork. It would reduce security for those who are using it right now.
Though, could always stop providing that public service and call it a Kicksecure specific fork.
Or compile it twice during build if that is possible (probably is). The default, not-used by default hardened-malloc package and perhaps hardened-malloc-kicksecure - the latter could be installed to a different path and enabled by default.
That would be the best choice. Users could use the default hardened_malloc for some applications if they want for the extra security features.
@madaidan yet another option: is there a way to blacklist the apps that run into problems when running under the standard hardened_malloc and maybe redirect them to the system default one? Can multiple mem allocators coexist on the same system?
Or maybe reserve the permissive fork for problematic programs and otherwise defer them to the more secure version (by default) as is from Micay?
Those problematic programs seem to be most things so it would make more sense to keep the permissive one as the default.
Managed to trim the config down to
CONFIG_SLAB_QUARANTINE_RANDOM_LENGTH=0 CONFIG_SLAB_QUARANTINE_QUEUE_LENGTH=0 CONFIG_GUARD_SLABS_INTERVAL=8
with the help of Daniel.
I’ve tried to implement this. What do you think?
I don’t want to fork any of the files shipped by upstream if not absolutely required.
make isn’t something I am comfortable with long term. However, if such
Makefile changes were upstreamed this were very much OK. But in this case I doubt upstream would accept a patch to introduce
libhardened_malloc_kicksecure.so: $(OBJECTS) and code duplication.
What upstream might accept is configuring the resulting “end product” (for lack for better term) file name
libhardened_malloc.so. I.e. could
libhardened_malloc.so: $(OBJECTS) be made configurable? If not set, default to
libhardened_malloc.so. If set, use that filename set from a make variable.
make clean. More appropriate and future proof.
Here is an approach which would not need any upstream patches, which doesn’t require modifications of files shipped by upstream that should be sold.
override_dh_auto_build: dh_auto_build -- libhardened_malloc.so CONFIG_NATIVE=false CC=$(CC) mv libhardened_malloc.so libhardened_malloc.so_original make clean dh_auto_build -- libhardened_malloc.so CONFIG_SLAB_QUARANTINE_RANDOM_LENGTH=0 CONFIG_SLAB_QUARANTINE_QUEUE_LENGTH=0 CONFIG_GUARD_SLABS_INTERVAL=8 CC=$(CC) mv libhardened_malloc.so libhardened_malloc.so_kicksecure
libhardened_malloc.so_original usr/lib/libhardened_malloc.so/libhardened_malloc.so libhardened_malloc.so_kicksecure usr/lib/libhardened_malloc.so/libhardened_malloc_kicksecure.so
Would that work?
Yes, that’d be perfect.
Could you do a new test / PR please?
Where should this be enabled? A new package -
That… Is a good question… I was thinking about how to best enable this.
Only option seems to be this:
/etc/ld.so.preload. Would be a bit troublesome because there is no drop-in folder at time of writing.  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
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”.
 related feature request:
/etc/ld.so.preload.d drop-in configuration folder support
Installation path was actually wrong. Found a fix.
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