9

For some highly secure bastion VMs I'll implement soon, I am considering to unmount /boot after booting - among other measures of course. Will be mounted only for updating kernel.

  • Testing this, no problems seem to appear; can it have any side effects I'm missing?
  • 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.
  • 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.
  • 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?
Improve this question
12
  • 21
    Security against what? Please share the possible attack scenario(s) you want to defend.
    – Philippos
    Apr 5, 2022 at 7:13
  • 2
    It doesn't matter; the demand is to minimize attack surface at all possible directions. Many other measures will be taken, I'm asking for something very specific.
    – Krackout
    Apr 5, 2022 at 7:33
  • 14
    You can be caught in a rabbit hole very quickly if you look at "all possible directions". Consider the actual return on a given action (for example, a user who could affect files in /boot would already have privs to mount /boot) and weigh them against difficulty in implementing and in possible consequences.
    – doneal24
    Apr 5, 2022 at 18:23
  • 3
    When exactly would an attacker have been able to modify anything in /boot if it were mounted, but not be able to just remount it?
    – Joseph Sible-Reinstate Monica
    Apr 6, 2022 at 1:40
  • 17
    @Krackout If someone asks me how thick an aluminium hat needs to be for protection, the question is very specific, but I will still ask back: Protection against what?
    – Philippos
    Apr 6, 2022 at 5:49

6 Answers 6

Reset to default
25

In theory neither /boot/ nor /boot/efi are commonly used after boot. The two form a bridge between the BIOS (or similar) and the operating system. They are not generally used at runtime.

They are mounted so that the you can re-configure your boot and so that your OS can update / upgrade its boot sequence. That is, on Debian, apt/dpkg will trigger changes to both.

Besides dpkg (or rpm on redhat derivatives) it would be unlikely for anything to want access to the /boot file tree.

From a security perspective I'd challenge the wisdom of unmounting either. They both should be read-only to all users except root. If a user gains root access then they could just mount them. On the other hand preventing your system from applying updates (including security patches) might open more holes than you close.

Instead, have you considered isolating bastion access with chroot etc.? Chroot lets those logged in only access a child file tree and a pid namespace and user namespace can protect against something escaping (chroot alone isn't enough).

The easiest way to do this might be to replace your SSH server with docker (or podman) running openssh inside a container. That would leave any SSH clients inside a docker container than would have no sight of the host system. The filesystem inside that container could be really minimal such as an alpine linux container with almost nothing but a minimal command line.

Note for clarity: chroot is not enough to isolate a process. With root access, a process can escape chroot. However other isolations such as pid and user namespaces and dropping capabilities should do a lot to secure a process inside a chroot jail... Hence the suggestion of using docker.

Improve this answer
5
  • There is already a plan for further isolation using LXC inside the VM.
    – Krackout
    Apr 5, 2022 at 9:57
  • 2
    It may prevent an accidental delete helping in more resilient system. Even in case of breaking in, one step more will be needed, which may help in tracing afterwards. It's a simple move, nothing to lose (since updating of these systems will be controlled whatsoever) and it may give a very small advantage in security and resiliency.
    – Krackout
    Apr 5, 2022 at 10:40
  • 6
    @Krackout a safer way to do that is remove all root access from the VM and tear it down / re-create it when you need to make changes. This is one major advantage of VMs over bare metal servers.
    – Philip Couling
    Apr 5, 2022 at 20:29
  • 5
    Chroot is not considered a safe way to isolate part of the system, unless things have changed a lot the last few years. Do you have a reference to why it might be considered safe these days?
    – l0b0
    Apr 5, 2022 at 21:36
  • @I0b0 I didn't emphasise the point but the pid namespace and user namespace does a lot to prevent breaking out of the container. That and dropping capabilities. An unprivileged container in docker is pretty secure by default. Chroot on its own isn't enough ( you are right on that point)
    – Philip Couling
    Apr 5, 2022 at 22:31
16

Side effects : None that I have ever noticed myself. Apart of course from the burden brought by the necessity to be certain to have it mounted prior to installing a new kernel. (be certain because in case it is not, installing will gracefully and silently install the kernel in the root's /boot directory…)
The benefits in terms of security are however debatable.

The proper way to proceed (whatever the init system) is almost certainly to… not mount it at bootime… since it is never actually needed ;-P
Check for the associated entry in your fstab and simply add a noauto parameter, this could look like : LABEL=LTUX_BOOT /boot ext4 noauto,noatime 0 2

If you definitely want to have it mounted (in order to umount later) you can benefit from the x-systemd.idle-timeout feature of the mount system. Adding something of the like noauto,x-systemd.automount,x-systemd.idle-timeout=1s to the /boot entry of your fstab would have its filesystem automatically unmounted after 1 second of iddle time.

Improve this answer
9
  • 3
    I'm impressed! It had never occurred in my mind that /boot does not need to be mounted at all. I actually commented out the /boot line in fstab, rebooted, everything worked smoothly.
    – Krackout
    Apr 5, 2022 at 10:35
  • 2
    @ArtemS.Tashkinov : Well, has anyone ever needed luck doing make install in the /usr/src/linux dir ? or /sbin/dolilo ? or whatever ? BTW, as far as I am concerned, it is not for security reasons that I do not mount boot at init time. It is simply because I like keeping my process table as slim as possible ;-P And at the end of the day… I am happy to leave to others the arguments in favor of having a computer doing absolutely useless tasks.
    – MC68020
    Apr 5, 2022 at 13:26
  • 2
    the presence of /boot does not affect "process table". Here on my Fedora 35: sudo lsof -n | grep /boot -> nothing. Normally GRUB loads files from it during boot and that's it.
    – Artem S. Tashkinov
    Apr 5, 2022 at 14:02
  • 3
    @ArtemS.Tashkinov : Yes it does. What about the [jbd2/sd…] and [ext4-rsv-conver] kernel threads I get for each mounted (journaled+writeback) filesystem ? Anyway, forget it. My point is more about doing something useless vs not doing it at all.
    – MC68020
    Apr 5, 2022 at 14:23
  • 3
    @ArtemS.Tashkinov Do you have a reference that ext4 journaling doesn't help preserve data? Conseptually journaling is used to avoid corrupted data in the event of a crash.
    – Philip Couling
    Apr 5, 2022 at 22:52
9

Now that I think about it, you are asking this from the specific point of view of a bastion virtual machine. These typically are stateless with very little installed.

If you are remotely concerned about the damage that a hacker could do using /boot then the majority of that damage would take effect when the VM restarts.

If you wanted an extremist view of this, you could actually completely destroy your boot partition and after boot. It's a VM after all. To "reboot" or even apply security updates you just spin up a new VM and tear down the old one. Then there's "nothing" a hacker could do to interfere with the VM's boot sequence.

As stated in my other answer, there's no real reason to keep /boot and /boot/efi mounted except for applying security updates.

Improve this answer
2
  • 1
    It's a VM. It can be configured to only boot an ISO from the host filesystem. Nobody's overwriting that from inside the VM unless they have a VM escape.
    – Joshua
    Apr 7, 2022 at 18:36
  • This answer hits it. In fact, VMs often don't even need a /boot – boot a kernel with an initrd directly from the hypervisor.
    – Marcus Müller
    Apr 8, 2022 at 11:23
6

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 /boot.
  • 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).

Improve this answer
6
  • All the answers are helpful, I'm changing to this as giving the proper answer since it's the most complete. Nice point regarding secure boot on UEFI; unfortunately due to custom kernel modules - a demand for some custom virtual devices - the kernel will be tainted; I think secure boot cannot be enabled on a tainted kernel.
    – Krackout
    Apr 5, 2022 at 19:23
  • 1
    @Krackout You can still use Secure Boot in that case, you just get no guarantees after the handoff from the bootloader to the kernel itself (and thus probably can’t leverage a complete trusted computing stack). Whether that more limited security guarantee is worth it for you or not is another matter though.
    – Austin Hemmelgarn
    Apr 5, 2022 at 19:26
  • @Krackout, secure boot can indeed be enabled on a tainted kernel. To load modules and thus "taint" it, you boot it first. A bootloader verifies the signature of the cold kernel before executing it. ("Tainting" specifically means loading non-GPL modules; you probably want your modules be signed, but their license is irrelevant). Also consider measured boot.
    – kkm -still wary of SE promises
    Apr 6, 2022 at 14:24
  • 2
    @kkm Actually, non-GPL licensing is only one potential cause. There are a whole slew of others that have absolutely nothing to do with module licensing. MCEs, kernel warnings/OOPSs/BUGs, out of tree modules (even if GPL-licensed), and loading staging drivers will all taint the kernel for example (and there are plenty of other possible causes as well).
    – Austin Hemmelgarn
    Apr 6, 2022 at 14:57
  • @AustinHemmelgarn, thanks, I didn't know. Should do my reading now. :) I hope I still have a point: a kernel can hardly be tainted before it's booted.
    – kkm -still wary of SE promises
    Apr 6, 2022 at 15:10
5

/boot is typically used by the bootloader, usually by GRUB. In typical usage, /boot will contain any bootloader configuration files that might need updating on kernel updates, and the kernel and initramfs files for the installed kernel version(s). If the bootloader requires some other files, they can be placed in /boot, too.

Since the bootloader needs to run before the OS kernel is present, it cannot rely on Linux kernel concepts like "mounting a filesystem". Instead, when the bootloader accesses a filesystem, it must do it using either firmware support (EFI System Partition on UEFI systems) or the bootloader's own filesystem drivers. Such bootloader-level drivers are usually simplified and offer read access only, using no advanced caching or any other methods for increasing performance, as their only job will be to load the few files needed to boot the OS kernel.

You cannot normally transfer the state of the bootloader's filesystem driver into the kernel's control, and since the kernel normally has more higher-performance filesystem drivers anyway, you wouldn't even want to.

Once the bootloader has successfully loaded the kernel (and in case of Linux, usually also the initramfs file) to RAM memory and started the kernel, the job of the /boot filesystem is essentially done. Neither the Linux kernel nor the initramfs file will typically require anything further from the /boot filesystem. The only reason to mount /boot as part of the system boot-up is to have it readily available in case kernel updates will be installed.

And so, the best way to "unmount /boot after booting" is, in the vast majority of cases, is to simply comment it out of /etc/fstab or add a noauto mount option to it, i.e. not mount it at boot time in the first place.

There seems to be a set of standard directories for scripts to be run at kernel updates:

  • /etc/kernel/preinst.d/ for scripts that should run before installing a new kernel
  • /etc/kernel/postinst.d/ for scripts that should run after installing a new kernel
  • and /etc/kernel/prerm.d/ and /etc/kernel/postrm.d/ for scripts that should run before & after removing an installed kernel, respectively.

The scripts in those directories will be executed in the usual US-ASCII sort order by filename. If you place a script to mount /boot as /etc/kernel/preinst.d/000-mountboot and /etc/kernel/prerm.d/000-mountboot and another script to unmount it again as /etc/kernel/postinst.d/zzz-umountboot and /etc/kernel/postrm.d/zzz-umountboot, you should get exactly the functionality you want, assuming your distribution's standard kernel packages are built to call these scripts in the proper phases.

The ESP partition of UEFI (often mounted as /boot/efi) is exactly the same, but for the system firmware instead of the bootloader. As soon as the firmware has successfully loaded the bootloader *.efi file from the ESP partition (and any supplementary files the bootloader might have there), ESP's primary job will be done and it won't be needed again until a bootloader update or the next boot cycle.

However, the UEFI ESP partition can have a secondary function: if the UEFI firmware supports "firmware update capsules" (i.e. a standardized way for scheduling a system firmware update from within a running OS), the firmware update files would need to be written to the ESP before setting up the update process. Linux has tools to use this mechanism: see the man pages for commands fwupdate, fwupdmgr and/or fwupdtool. If this mechanism will eventually take the place of vendor-specific UEFI/BIOS update tools, you will have at least two conditions when the ESP must be mounted:

  • when installing a bootloader update
  • when installing a UEFI firmware update

For now, there does not seem to be a standard hook for adding custom scripting to these events, unlike the case for kernel updates.

Improve this answer
3
  • The question mentions a VM. It's much more natural to rebuild it instead of upgrading critical components, like the bootloader or the kernel, which better be solidly read-only for a sensitive gateway. As for the UEFI "firmware," it is upgraded by the VM's host, as part of the hypervisor upgrade, and is immutable from inside a VM.
    – kkm -still wary of SE promises
    Apr 6, 2022 at 14:47
  • @kkm You're absolutely correct. I got interrupted when writing my answer, and looks like I forgot the VM detail. Well, perhaps my answer is of some use to someone else.
    – telcoM
    Apr 6, 2022 at 14:53
  • It certainly is! :)
    – kkm -still wary of SE promises
    Apr 6, 2022 at 15:08
3

Unmounting /boot after the OS is up is certainly possible. In fact it's standard practice on many Linux distros. The Gentoo guide certainly assumes it and I've done it on every Gentoo install I've ever done (which is a LOT).

Whether it achieves what you think you'll get from it is a completely different question.

Improve this answer
1
  • Interesting, thanks! I wondered why do Linuxen that I've used (RH, Debian, and, years ago, Ubuntu) have the ESP mounted as /boot, while Windows never has. It's good to know that there are distros that also don't, and the mount is probably just a historic compatibility artifact.
    – kkm -still wary of SE promises
    Apr 6, 2022 at 15:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .