Why not mount /boot?

Roken · 2020-03-05 21:30:28

I'm gonna post in here because it's probably where it will end up.

I'm a long time user (as my only OS), but in the past couple of days I'm seeing a lot of support requests that seem to be, on the face of it, not mounting /boot.

I have a separate boot partition mounted to /boot at startup.

Why would I NOT want to do this?

i.e. what are the risks associated with mounting /boot all the time?

Last edited by Roken (2020-03-07 07:46:34)

jasonwryan · 2020-03-05 21:43:07

I had always assumed it was a result of either a) people following stupid third party install guides, or b) rushing through the installation guide and not creating an fstab entry.

Previously, the issue would have been discovered at boot time, but now systemd prevents that from happening.

eschwartz · 2020-03-05 22:10:44

There's somehow the arcane idea in some very odd circles that you should always have it mounted, but have it mounted *read-only* except while doing kernel upgrades. So yes, it can in fact get even sillier than accidentally not mounting it at all.

frostschutz · 2020-03-05 22:33:31

It's a decades old religion security recommendation, following the principle of least privilege. A mounted /boot serves zero purpose to the running system (except when you update). Hard to tamper with /boot (deliberate or by accident) if it's not mounted. And similar such motivations. It's the default in some distros, Gentoo in particular has had it in its /etc/fstab template for as long as I can remember.

In my case there are practical reasons for it. My /boot is a USB stick, and by the time the system starts mounting filesystems, it might not even be plugged in anymore.

In ArchLinux specifically, unless you have good reason, you shouldn't use noauto. If you make it a separate partition at all, just leave /boot as auto mounted.

If you don't, pacman won't hold your hand. It won't check if /boot is mounted (you can force it to fail in the kernel update step by making umounted /boot immutable), and it will also remove old kernels and modules immediately so if your /boot didn't exist at the time of kernel update and you boot an old kernel as a result, you're usually screwed as you're left with zero kernel modules to use and initramfs only has the ones essential to the early boot process.

WorMzy · 2020-03-05 22:38:38

Roken, I've lost track of the amount of times you've been asked to pick meaningful topic titles. Consider this a final warning. Change your topic title to something that actually describes your question before you post again.

https://wiki.archlinux.org/index.php/Co … ow_to_post

eschwartz · 2020-03-05 22:43:10

frostschutz wrote:

It's a decades old religion security recommendation, following the principle of least privilege. A mounted /boot serves zero purpose to the running system (except when you update). Hard to tamper with /boot (deliberate or by accident) if it's not mounted. And similar such motivations. It's the default in some distros, Gentoo in particular has had it in its /etc/fstab template for as long as I can remember.

But... you could say the same thing about /usr and /opt. It's only logically coherent to say this about /boot if you say it for all three.

frostschutz wrote:

In my case there are practical reasons for it. My /boot is a USB stick, and by the time the system starts mounting filesystems, it might not even be plugged in anymore.

That would be for not mounting it at all, sure.

My personal preference, though, would be to make my ESP a USB stick, but not mount it to /boot, and use grub or refind to load an ext4 root partition which includes /boot.

frostschutz · 2020-03-05 23:14:20

eschwartz wrote:

But... you could say the same thing about /usr and /opt.

If you don't mount /usr(*) or /opt, stuff stops working. That's where you have binaries, libraries, databases etc. you need to run the system. You can't not mount those. (If you meant read-only /usr, yeah I guess there are those that do that)

If you don't mount /boot, nothing whatsoever happens. /boot has nothing. The bootloader has already done its work and the kernel is already in RAM. /boot is done the moment the system starts booting. There's simply no point in mounting it.

If you want to look for another example, it'd be backups.

The backup partition, you either don't mount it at all, or only when you actually make a backup, or if you must keep it mounted all the time then at least make it read-only.

Keeping backups around in read-write all the time would serve no purpose, it'd only allow tampering, whether deliberate or by accident.

I don't propose you do that or whatever, just that's the thinking behind it as far as I'm aware. That it works particularly badly for umounted /boot in ArchLinux doesn't make it right or wrong, that's just circumstance.

(*) With any luck, we're past making separate partitions for /usr, yes? Yet ArchLinux offers explicit support for this configuration, though it's just as ill-conceived as non-mounted /boot. It's something a lot of people do or did without a specific reason to it. Why explicitely support one but not the other, again circumstance. It just turned out this way somehow.

Last edited by frostschutz (2020-03-05 23:20:03)

eschwartz · 2020-03-05 23:38:53

frostschutz wrote:

eschwartz wrote:
But... you could say the same thing about /usr and /opt.
If you don't mount /usr(*) or /opt, stuff stops working. That's where you have binaries, libraries, databases etc. you need to run the system. You can't not mount those. (If you meant read-only /usr, yeah I guess there are those that do that)

I did indeed mean read-only.

frostschutz wrote:

If you want to look for another example, it'd be backups.
The backup partition, you either don't mount it at all, or only when you actually make a backup, or if you must keep it mounted all the time then at least make it read-only.
Keeping backups around in read-write all the time would serve no purpose, it'd only allow tampering, whether deliberate or by accident.

In the case of backups, there is a specific conceptual goal to mounting them read-only, as their "theme" is to be tamper-proof and e.g. they are intended to prevent catastrophes where, idk, some rogue rm -rf / deletes everything. Failure to achieve their fundamental goal is a big issue. You wouldn't bother having backups unless you were concerned that something could eat your data, so you do what you can to make sure that things which unexpectedly eat your data cannot eat the backups.

There's no fundamental conceptual goal to mounting /boot read-only (or explicitly wanting it to be unmounted, beyond practical issues like being a USB drive). It's completely based around the idea of "I dunno, why not?" and *that* I strongly disagree with.

(It's not a security concern, and the highly specific goal of backups is not applicable here.)

frostschutz wrote:

I don't propose you do that or whatever, just that's the thinking behind it as far as I'm aware. That it works particularly badly for umounted /boot in ArchLinux doesn't make it right or wrong, that's just circumstance.
(*) With any luck, we're past making separate partitions for /usr, yes? Yet ArchLinux offers explicit support for this configuration, though it's just as ill-conceived as non-mounted /boot. It's something a lot of people do or did without a specific reason to it. Why explicitely support one but not the other, again circumstance. It just turned out this way somehow.

There's nothing wrong with separate partitions for /usr, as far as I'm aware. I would not advise against having any of them unavailable ever, but, they seem to serve somewhat of a purpose for multiple disks. Some might prefer using certain RAID levels, disk spanning, or btrfs/zfs additional devices (software RAID), but the availability of such functionality doesn't make partitioned /usr fundamentally wrong.

(Also, Arch doesn't either support it or refuse to support it. People do it, the wiki contains information that users feel is useful to understand the hows and whys, and genfstab incidentally supports it as a side effect of also supporting /media so uh, I guess if you squint we do indeed support it.)

frostschutz · 2020-03-06 00:09:19

eschwartz wrote:

In the case of backups, there is a specific conceptual goal to mounting them read-only, as their "theme" is to be tamper-proof and e.g. they are intended to prevent catastrophes where, idk, some rogue rm -rf / deletes everything.

Tamper-proof is also a theme for /boot. That's how secure boot and the whole signing business came about.

For rm /* it'd delete /boot right after /bin too, one of the first things gone even if you Ctrl-C it quickly.

For a local system a botched /boot is an easy fix, for remote system it can be more difficult.

Anyway, not much point discussing it. There's not really any right and wrong, just plenty of ways to set things up in Linux... comes down to personal opinion and priorities.

eschwartz · 2020-03-06 00:22:35

frostschutz wrote:

Tamper-proof is also a theme for /boot. That's how secure boot and the whole signing business came about.

Secure boot and signing has nothing to do with rm anything. Unmounting /boot does not protect it from any form of attack, ever, only carelessness. Unmounting /boot is not a security routine, and even if it were, there are lots of more important targets such as /sbin/init (symlink to /usr/lib/systemd/systemd) or /lib/modules/

frostschutz wrote:

For rm /* it'd delete /boot right after /bin too, one of the first things gone even if you Ctrl-C it quickly.
For a local system a botched /boot is an easy fix, for remote system it can be more difficult.
Anyway, not much point discussing it. There's not really any right and wrong, just plenty of ways to set things up in Linux... comes down to personal opinion and priorities.

Yeah so uh, that's not actually the point. The point is that if anything whatsoever gets deleted, you're hosed, it doesn't matter whether /boot is included within that. Fixing a hosed /bin and /usr/bin on a remote system is just as hard as fixing a hosed /boot.

And still, "backup" disks remain all alone as something thematically useful to keep unmounted.

There is most certainly right and wrong. Anyone claiming that there isn't, is really intending to quibble over how you define "that which is wrong".

I will steadfastly insist that "wrong" is "keeping /boot unmounted with the rationale that it is a security routine". I don't care if you (rhet.) keep it unmounted, but if you're going to do it, don't do it for completely incorrect reasons.

seth · 2020-03-06 07:36:42

1. You're booting from a removable device (mounting spoils the "removable" part)
2. You cannot™ mount from a removable device (ie. the HW is locked and sealed and whatnot) and seek to protect against beauties like "sudo rm -r somepath /" (which is more likely to happen if the last letter in path is close to the space bar ;-)
The latter is a real thing w/ (somewhat) public terminals. It could be real w/ remote systemsas well, but in any event requires the initramfs holds a complete stack to open an ssh connection (in or out) or eg. a tiny rescue system and memdisk that for remote systems also auto-boots if the default boot fails in rapid™ succession.

ANY sEcUrItY argument is complete BS itr.
You need UID0 privs to write there and if I have UID0, I can mount whatever I want, wherever I want.

tl;dr:
For Joe User, NOT mounting /boot will cause more harm (hence the recent threads) than good. Mostly because there's no real good to begin with.
Whether that's "wrong" is, to my understanding of the English language, a moral question that you can go ask a priest about.
But it's a bad idea for sure.

Roken · 2020-03-06 11:25:48

WorMzy wrote:

Roken, I've lost track of the amount of times you've been asked to pick meaningful topic titles. Consider this a final warning. Change your topic title to something that actually describes your question before you post again.
https://wiki.archlinux.org/index.php/Co … ow_to_post

Thanks, Wormzy.

In this case, short of posting the entire question in the title, what would you suggest?

seth · 2020-03-06 11:50:01

You ask a question, so the subject should probably have a question mark.

In this case, how about eg.

[RFC] Keep /boot partition mounted all the time?

qinohe · 2020-03-06 13:52:04

seth wrote:

...
2. You cannot™ mount from a removable device (ie. the HW is locked and sealed and whatnot) and seek to protect against beauties like "sudo rm -r somepath /" (which is more likely to happen if the last letter in path is close to the space bar ;-)

Yes you can, you need to only use it ; path-completion;)

Steo · 2020-03-06 20:53:21

I have systemd and my /boot is actually mounted when the system boots. Does having it mounted actually cause any issues other than the fact that a user could accidentally delete/break it?

If having it mounted is actually bad, does this just mean mounting it for a kernel update then unmounting it again? Sorry if this sounds dumb, I just never thought there could be an issue with having it mounted.

V1del · 2020-03-06 21:03:55

If you read this very thread, that asks this exact question, you will notice that the large consensus is to have it mounted to prevent issues precisely due to the fact that people forget to mount it during kernel updates and no there is no actual issue to it other than the user could accidentally break it (outside from actively malicious applications, but at that point as an attacker would need root and as root he could just mount /boot again, or worse...)

CarbonChauvinist · 2020-03-06 21:05:35

Steo wrote:

Sorry if this sounds dumb

It doesn't, it just sounds like you posted in the thread without reading any of the prior posts which literally discuss exactly the points you're asking about.

jasonwryan · 2020-03-06 21:23:54

Seventeen posts in and still the same useless title...

Steo · 2020-03-06 21:23:59

V1del wrote:

If you read this very thread, that asks this exact question, you will notice that the large consensus is to have it mounted to prevent issues precisely due to the fact that people forget to mount it during kernel updates and no there is no actual issue to it other than the user could accidentally break it (outside from actively malicious applications, but at that point as an attacker would need root and as root he could just mount /boot again, or worse...)

That's ok then, it just makes kernel upgrades much easier that way if I keep it mounted. It will be my own fault if I manage to break it, and it would be easy enough to fix anyway with chroot.

CarbonChauvinist wrote:

Steo wrote:
Sorry if this sounds dumb
It doesn't, it just sounds like you posted in the thread without reading any of the prior posts which literally discuss exactly the points you're asking about.

I did read, and some people in the earlier posts were saying that they don't mount it, mount it as read only, or use a removable device, which was why I decided to ask in case there was any sort of benefit to doing so.

EDIT: My apologies regardless, I just wanted to ask to be sure I wasn't doing something silly by having boot mounted as rw.

Last edited by Steo (2020-03-06 22:02:13)

Roken · 2020-03-07 07:47:16

jasonwryan wrote:

Seventeen posts in and still the same useless title...

Apologies, I don't spend my whole life here, and have only just logged back in.

Arch Linux

#1 2020-03-05 21:30:28

Why not mount /boot?

#2 2020-03-05 21:43:07

Re: Why not mount /boot?

#3 2020-03-05 22:10:44

Re: Why not mount /boot?

#4 2020-03-05 22:33:31

Re: Why not mount /boot?

#5 2020-03-05 22:38:38

Re: Why not mount /boot?

#6 2020-03-05 22:43:10

Re: Why not mount /boot?

#7 2020-03-05 23:14:20

Re: Why not mount /boot?

#8 2020-03-05 23:38:53

Re: Why not mount /boot?

#9 2020-03-06 00:09:19

Re: Why not mount /boot?

#10 2020-03-06 00:22:35

Re: Why not mount /boot?

#11 2020-03-06 07:36:42

Re: Why not mount /boot?

#12 2020-03-06 11:25:48

Re: Why not mount /boot?

#13 2020-03-06 11:50:01

Re: Why not mount /boot?

#14 2020-03-06 13:52:04

Re: Why not mount /boot?

#15 2020-03-06 20:53:21

Re: Why not mount /boot?

#16 2020-03-06 21:03:55

Re: Why not mount /boot?

#17 2020-03-06 21:05:35

Re: Why not mount /boot?

#18 2020-03-06 21:23:54

Re: Why not mount /boot?

#19 2020-03-06 21:23:59

Re: Why not mount /boot?

#20 2020-03-07 07:47:16

Re: Why not mount /boot?

Board footer