Testing this, no problems seem to appear; can it have any side effects I'm missing?
No, not really, except that some tools may actually need it mounted that you may have not thought of (for example, GRUB will need it mounted whenever it gets updated, not just for kernel updates).
The systems will be probably based on Debian Linux (other scenario, on Redhat). Both are systemd. What is the proper way to unmount /boot on a systemd system after reboot? For testing I just sudo umount /boot.
As pointed out elsewhere, just don’t mount in the first place. Simply add
noauto to the options in the
/etc/fstab entry for it.
I'm debating myself if I'm going to use BIOS or UEFI. As they will be VMs, it's a matter of choice. UEFI appears to be a more sane choice as more modern. But I'm not sure regarding security benefits, if any. On the contrary, because it's more complicated, more chances of vulnerabilities perhaps.
If you use UEFI you can, theoretically, avoid ever even needing a boot loader, but doing that with Debian (and most other Linux distros other than Gentoo) is exceedingly complicated.
UEFI also is usually required for Secure Boot, which it sounds like you probably want, though that’s tricky to get right in a VM.
Other than that, there’s not much benefit one way or the other, because you cannot audit the code involved in either case (which means you cannot reason properly about either option being more secure than the other).
In case of UEFI, what about efi partition? It's mounted inside /boot by default, although I think /efi can be used (I haven't tried it), to separate them and handled more transparently, administrator side. Can /boot/efi or /efi be unmounted as well after boot without side effects?
Same comments as for
/boot. It can be mounted anywhere though, but convention indicates that
/boot/efi is the expected mount point.
The reason for this is twofold:
- It makes writing security policies for path-oriented mandatory access control systems (like AppArmor) easier, because they can just have a blanket clause for everything under
- It keeps things organized where they arguably should be. Stuff involved in booting the system is put under
/boot, as it has been on most UNIX-like systems for a very long time.
As an aside, this does not actually provide a significant improvement to security relative to the overall difficulty involved in doing it right.
The normal way to secure
/boot is to make sure it’s not writable by anybody but the root user, or if you’re feeling especially paranoid, not readable or traversable by anybody other than root either. Such an approach means that anybody who does not have an EUID of 0 or the CAP_DAC_OVERRIDE capability cannot modify anything under
/boot, but, notably, does not require any special handling to make updates work properly.
Your approach also means that anybody who does not have an EUID of 0 or the CAP_DAC_OVERRIDE capability (someone with this capability can, for example, rewrite
/etc/fstab so that
/boot does get mounted on boot, and then find any of a number of creative ways to force a reboot of the system, or as another example could just write directly to the underlying block device instead) cannot modify anything under
/boot, but only when there is nothing legitimately modifying anything under
/boot (because legitimate modification requires
/boot to be mounted). It also requires special handling to ensure kernel updates, bootloader updates, and a small selection of other types of updates (such as third-party kernel module updates) work correctly. Note that automounting it does not work here, because if you set up automounting then someone just has to try to access the directory to mount it.
Note that your approach provides no significant protection against a dedicated attacker, but makes it more likely that you will actually break something by accident (for example, but running updates without it mounted).