The System.map files should be removed. By default, /boot/System.map-* contains kernel symbols which could be useful to an attacker. Setting kernel.kptr_restrict=2 hides these from /proc/kallsyms but an attacker can just look at the System.map files to get the symbols anyway.
These could possibly be purged during the build or at boot with a systemd service.
Tails also removes these.
System.map files are only used for debugging or malware.
It may be useful to disable the SysRq key too. It allows anyone to use certain commands that the kernel will do regardless of what it’s currently doing. It can be disabled with sysctl using kernel.sysrq=0. I am not too sure about this one though.
if I were you I’d just write a generator that looks at /etc/fstab and creates drop-ins for the .mount units systemd-fstab-generator generates that override the Option= line. i.e. let systemd-fstab-generator do its thing as it currently does (meaning: translating fstab into native systemd .mount unit files), but then have your own generator that tweak some of these mount units with additional generated drop-ins as you need.
Can you make head or tail of it?
We don’t have to make it as complicated as having our own generator. Hardcoding the few option we need in drop-in config files would suffice.
Btw there are files in /run/systemd/generator/ which are # Automatically generated by systemd-fstab-generator if that helps.
Should security-misc also disable coredumps? For distros that have them enabled by default.
It wouldn’t be needed on Whonix as Debian disables them by default and Whonix doesn’t re-enable them but it may be useful for other distros that are using security-misc.
I can add systemd sandboxing if needed (likely not).
I am wondering if systemd sandboxing can do more harm than good here.
What’s the threat model? /proc containing at early boot something
malicious, which would upon using mount with remount options, result
in exploiting a vulnerability in mount, then leading to root compromise?
On the other hand, any (distribution) upgrade of kernel, mount or any
dependent libraries requiring any new seccomp could lead to remount fail
“in the middle”, hence end up with an unbootable system?
I just think we should sandbox as much as possible, especially root processes. A compromised systemd service could pretty easily be turned into a rootkit.
That’s unlikely as I doubt mount will be updated much and this is what testers versions are for. Any major kernel update will likely be part of the testers only version of Whonix. I could remove the syscall filter so it’d be even more unlikely for it to break.