/sys/kernel/debug/ is the usual mount point for it and it’s already restricted to root in Debian by default so we can’t do any permission hardening with it in security-misc.
We can’t just restrict this with apparmor-profile-everything. debugfs doesn’t have to be at /sys/kernel/debug/. An attacker can mount it anywhere. For example, run
mount -t debugfs none /mnt
Now there is a debugfs mounted at /mnt. If apparmor-profile-everything denied access to /sys/kernel/debug/, it will do nothing to stop the attacker from just accessing this new mount at /mnt.
Unless, during the install we find out what hardware the user uses, select config options based on that and compile the kernel although this can easily go very wrong.
Better to rename from hardened-vm-kernel to hardened-kernel? Reason is the compile script and install hacks might be shared. Ideally for host kernel we’d offer precompiled but with a drop-in config snippet we’ll let the user opt-in for local self-compilation. Using all the same code but just some variables change depending on VM or host.
Various /proc files exist to monitor process memory utilization:
/proc/pid/smaps, /proc/pid/clear_refs, /proc/pid/pagemap,
/proc/kpagecount, and /proc/kpageflags. Disabling these
interfaces will reduce the size of the kernel by approximately 4kb.
It was called “brain-dead” and a security risk by grsecurty.
It was also used in exploiting rowhammer to gain kernel privileges.
Not a lot has happened to security-misc in Qubes outside of Qubes-Whonix. Maybe more realistic to develop Kicksecure and then create a Kicksecure Qubes template. That might meet lower resistance than hardening Qubes Debian template.
Feel free to open any Qubes tickets.
As for outreach hardened-vm-kernel seems useful to contact both linux-hardened and oss-security mailing list.
perf exposes tons of debugging functionality that’s not really used much and should be disabled. It’s been the source of many infoleaks and vulnerabilities. Debian restricts this to root by default but that’s not enough for us.
The problem with disabling it though is that CONFIG_KVM and CONFIG_X86 both select CONFIG_PERF_EVENTS even though it isn’t strictly required. So, we’d need to patch the Kconfig and comment it out.
We can create a /usr/share/hardened-vm-kernel/patches/ directory and modify the build script to apply everything in there e.g.