Maybe we can parse the mount options to only remount it if it’s already ro?
if mount | grep "${rootmnt}" | grep "ro"; then
remount="yes"
mount -o remount,rw "${rootmnt}"
fi
sysctl -p ${rootmnt}/etc/sysctl.conf >/dev/null 2>${rootmnt}/var/log/sysctl-initramfs-error.log
sysctl -p ${rootmnt}/etc/sysctl.d/*.conf >/dev/null 2>>${rootmnt}/var/log/sysctl-initramfs-error.log
if [ "${remount}" = "yes" ]; then
mount -o remount,ro "${rootmnt}"
fi
grep -v "unprivileged_userfaultfd" "${rootmnt}/var/log/sysctl-initramfs-error.log"
sysctl-initramfs has an issue vs grub-live. In case of booting into live mode, we shouldn’t write to the root image. Maybe this could help:
if grep -qs "boot=live" /proc/cmdline; then
There are also other cases (security-misc is a general package. Don’t just focus on Whonix / Kicksecure) where writing to the root image might be unwanted. It’s not up to initramfs stage (security-misc / sysctl-initramfs) to know what shall happen with root image write policy.
/run/initramfs already exists. Therefore log location /run/initramfs/sysctl-initramfs-error.log would be better since ephemeral, in RAM, not on persistent disk. Will implement.
But the error log is weird. Added xxxxxxxxxxxx to some sysctl.d file.
cat /run/initramfs/sysctl-initramfs-error.log
sysctl: bad line 9: 1 tokens found, 2 needed
Looks fine when running sudo sh -x /etc/initramfs-tools/scripts/init-bottom/sysctl-initramfs but weird log when this is done in initramfs at boot. But I guess good enough.
ufw doesnt block ICMP - wiki fixation reminded me, perhaps there are some other ICMP related settings worth flipping? For example, you have this already covered:
Shutting it down can destroy performance for async IO applications like databases.
I don’t think we depend on it for build debugging - similar to ptrace’s situation. Should be included in the debug functionality disabling package.
This one might break Java programs and cross compiling builds for other archs with QEMU. You might want to document that in case users show up with mysterious bug reports.
I think the performance loss is worth it. Asynchronous I/O in general adds a lot of complexity and attack surface to the kernel. POSIX AIO is especially atrocious.
It’s already disabled in hardened-kernel and I see no issues.