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.
rm *.o
Better run 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.
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”.
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:
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”.
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.
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.
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.
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.
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.
Enabling /usr/lib/libhardened_malloc.so/libhardened_malloc_kicksecure.so by default should now be trivial thanks to hardened-malloc-kicksecure-enable package.
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:
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?
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?
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?
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)?