noauto option ignored in /etc/fstab?

[Josef Wolf]

On Thu, Dec 07, 2017 at 02:47:25PM +0100, Xen wrote:
> On Wed, 6 Dec 2017, Josef Wolf wrote:
> 
> >I am not ignoring you. In fact, I have actually replied to one of your mails.
> >
> >I don't see why unattended-upgrades needs /boot to be mounted ALL THE TIME. It
> >needs /boot to be mounted DURING THE UPGRADE. And in my reply to your mail I
> >have shown how this can be achieved.
> 
> Sorry didn't see that, but are you saying that you already solved the mount
> problem?

As I wrote in my response to you, I solved the mount problem by adding the
"noauto" into fstab and configuring apt like this:

  $ grep boot /etc/apt/*
  /etc/apt/apt.conf:DPkg::Pre-Invoke  {"/bin/mount -o remount,exec /tmp; /bin/mount /boot";};
  /etc/apt/apt.conf:DPkg::Post-Invoke {"/bin/mount -o remount /tmp; /bin/umount /boot";};
  $

This worked great for many years. Even with unattended-upgrades. The
Pre-Invoke and Post-Invoke would make sure /boot is mounted during the
upgrade.

The problem is that the "noauto" is ignored. Therefore, the Pre-Invoke will
fail, since /boot IS ALREADY MOUNTED. Thus, the whole upgrade will fail.

In addition, the md5sum-check will fail. This is because the mount/umount
commands will modify the filesystem.

> I am not certain unattended-upgrades is not started at boot. Most systemd
> services run for the entire duration of the system, so I supposed this was
> the case here too. So on my system, since boot 11 minutes ago,
> unattended-upgrades is *running*.

Unattended-upgrades did not interfere with my Pre-Invoke/Post-Invoke for many
years. Never had a problem. The problem arised only now, since grub-common
decided not to undo the mount it is doing at boot time.

> Even though I have disabled it in /etc/apt/apt.conf.d
> 
> And in fact it hasn't actually run since I disabled it; but that aside, the
> service is still running.
> 
> This service is also still pulling in boot.mount regardless of what it's
> doing.
> 
> So unless I am mistaken here and you have already solved the issue,
> as far as I can see your boot will be mounted until you disable
> unattended-upgrades.service.

Before the disk failed, I had 16.04 running for more than a year with
unattended-upgrades enabled. Never had a problem with that.

Therefore I guess, grub-common is causing the mount. But grub was also
installed on the old system. So maybe it's something in the grub config?

> [Unit]
> Description=Unattended Upgrades Shutdown
> After=network.target local-fs.target
> RequiresMountsFor=/var/log /var/run /var/lib /boot
> Documentation=man:unattended-upgrade(8)

Well, unattended-upgrades don't need /boot to be mounted all the time. It
needs it to be mounted during the upgrade. That's what the Pre/Post-Invoke are
for.

> >While this gives you an encrypted /boot, it won't buy you anything above an
> >unencrypted /boot. An attacker would simply modify grub to store the key
> >somewhere unencrypted.
> 
> Grub doesn't store the key. You mean the initrd?

Well, I should have written "password" instead of "key".

Unmodified grub doesn't store your password anywhere. Malicious grub could do
anything you can think of.

> Do you mean a physical attacker or a digital attacker?

This use-case is to guard against physical attacker. If a digital attacker can
modify your grub, you've already been blown up.

> >To prevent the attack, you have to make sure that you
> >never execute something that might have been manipulated. With encrypted
> >/boot, you have still to check grub.
> 
> That implies there would be another location on your laptop where a kernel
> and initrd can be stored, at which point the digital attacker has to rerun
> grub-install (or update-grub) with a different location to mount from; which
> would have to be encrypted with the same password, but your attacker doesn't
> know this password.

No.

The attacker can modify grub in-place. After all, Grub is not encrypted.

All the attacker needs is some space to store your LUKS-Password. Usually,
there's plenty of space between partitions, since fdisk and friends try to
honor cylinder boundaries (although this concept doesn't make any sense on
modern disks)

So, at boot time, you type your LUKS-PW. Malicious grub stores this PW
somewhere on your disk and proceeds as usual. You don't even notice, since the
boot process continues as usual.

Next time the attacker has access to your laptop, he can read the PW you typed
and use this to unlock your partition.

To prevent this attack, you need to check (with a live-CD) that your grub is
not modified. That's exactly what I do with my md5sum scripts. Since you have
to check grub anyway, there's no additional complexity to check the
unencrypted /boot partition along with grub.

> A LUKS password unlocks a header key. These header keys give access to the
> master key.
> 
> You cannot derive the password from the header key so easily, so the keyfile
> cannot be used to change or manipulate the master key, nor can you replace
> the passworded header key.

I know. And the attacker don't need to. All he needs to do is to store your
password somewhere verbatim (or encrypted with HIS key/pw) after you've
happily typed it into his malicious grub. With this, he can use any live-CD to
unlock your disk.

> This means that a *physical* attacker can never do this.

What, exactly, would prevent him from modifying your (unencrypted) grub?

> >And it buys you nothing, since you still have to check that
> >the (unencrypted) grub is not modified.
> 
> But this is where you are wrong because Grub doesn't store any keys.

Malicious grub can do anything you can dream of. I don't see what would
prevent malicious grub from storing your password somewhere on the system.

> No physical attacker is capable of pointing grub to a different location
> that will have the same password.

Malicious grub would be pointed onto the same location. Why would an attacker
need a different location?

> You have to TYPE IN A PASSWORD. Grub has no knowledge of keys.

Malicious grub would store this typed password. Attacker can use this password
to unlock your luks disk. No magic around here.

-- 
Josef Wolf
jw at raven.inka.de