Prevent runaway privileged processes from writing to block devices bdev_allow_write_mounted=0

[raja-grewal]

This pull request prevents processes from writing to block devices that are mounted by filesystems to protect against runaway privileged processes causing filesystem corruption and kernel crashes.

Credit to the kernel-hardening-checker tool for bringing this to my attention.

Note this is also now only possible using Debian 13 and so should be included in our upcoming port.

Changes

Set the bdev_allow_write_mounted=0 kernel boot parameter.

Mandatory Checklist

• Legal agreements accepted. By contributing to this organisation, you acknowledge you have read, understood, and agree to be bound by these these agreements:

Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint

Optional Checklist

The following items are optional but might be requested in certain cases.

• I have tested it locally
• I have reviewed and updated any documentation if relevant
• I am providing new code and test(s) for it

[ArrayBolt3]

This is good for hardening against user error I guess... and I suppose if a process managed to get access to the disk group but not gain real root access this could be useful. It might also be useful if a process managed to get root group access but not root user access. Users who need to do things like fsck or modifying ext4 filesystem features can just boot from a live USB. The kernel is even recommending that this feature be enabled by default. This seems like a reasonable thing to enable. I'll double-check that it functions as intended on Kicksecure 18 and merge it into my arraybolt3/trixie branch if so.

Edit: This parameter does work on Trixie, but it's usefulness for security is pretty low; it prevents /dev/vda2 from being written to directly, but not /dev/vda, for instance (this is on an installation without encryption). I think this is still worth merging, since it might thwart some forms of malware or at least provide additional frustration for attackers, but from a theoretical standpoint this provides no additional security.

[ArrayBolt3]

Merged into my arraybolt3/trixie branch.

[ArrayBolt3]

@raja-grewal, @adrelanos This option renders it impossible to mount NTFS volumes at least when using the mount command. By default, this uses the ntfs-3g FUSE driver, but this option prevents that driver from working since now a userspace application has to write to a block device the system sees as mounted. This means that if one does sudo mkfs.ntfs -Q /dev/sda1, then sudo mount /dev/sda1 /mnt, the mount command will fail with a "Device or resource busy" error. Removing this option from the kernel command line configuration resolves the issue.

This has also caused problems with zerofree, and telling users how to disable it has proven rather tricky in at least one situation. See https://forums.whonix.org/t/how-to-compress-and-prevent-vdi-from-ballooning-after-each-update-deleting-large-files/22675/9 and the conversation below.

Since this provides no theoretical security enhancements in most situations (as explained above), and runaway root processes are likely rare, I think this should be reverted.

Edit: This seems to also be causing some issues with fwupd, with messages like Feb 12 10:56:36 host fwupd[8963]: 10:56:36.047 FuEngine failed to add device /sys/devices/pci0000:00/0000:00:0d.0/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1: failed to subclass open: failed to open /dev/sda1: Device or resource busy.

[adrelanos]

Edit: This seems to also be causing some issues with fwupd, with messages like Feb 12 10:56:36 host fwupd[8963]: 10:56:36.047 FuEngine failed to add device /sys/devices/pci0000:00/0000:00:0d.0/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1: failed to subclass open: failed to open /dev/sda1: Device or resource busy.

What is fwupd attempting to do?

[ArrayBolt3]

What is fwupd attempting to do?

I believe it's trying to enumerate and probe all devices on the system so it knows what devices there are that might need firmware updates. (The code paths are a bit tricky to follow since fwupd uses a plugin architecture, but that's my best guess from the bits of code I could find.) Arguably it shouldn't be opening partition devices for that purpose (those will certainly never need firmware updates), but even if it didn't, it wouldn't fix the root issue since people can and do format whole disk devices with a filesystem in some instances.

[adrelanos]

• Make bdev_allow_write_mounted kernel parameter optional #362