noauto option ignored in /etc/fstab?

[Xen]

On Thu, 7 Dec 2017, Josef Wolf wrote:

> 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.

I understood your solution but I thought this was a new upgrade to 16.04, 
which is why I thought systemd caused the problems, my apologies.

> 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.

Okay I didn't follow that part of the thread; what grub-common could have 
anything to do with anything.

> 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?

So what can grub-common possibly do?

Grub has no role in the boot process after it passes control to the initrd 
(and kernel) and cannot pass on mounts to the running kernel.

Have you already tried disabling unattended-upgrades?

> 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.

Will you tell that to systemd?

Not to me ;-).

> 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.

Oh sorry. Yeah you are right.

Regardless that means they need to modify your grub, wait for you to boot, 
bypass your boot time verification code that they cannot access or change 
yet,

So you are correct but if you have verificaton code ON the system, it can 
detect the change.

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

So verification code running inside your encrypted system would be 
sufficient.

Of course you need it to email you or send notifications to whatever 
desktop system you have.

Of course at this point you don't know where the modified grub has stored 
your password.

If it uses the network it might already have sent it somewhere.




> 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)

Yeah, I got you now.

> 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.

But you can verify Grub ;-).

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

The attacker needs boot access or take out the harddisk.

> To prevent this attack, you need to check (with a live-CD) that your grub is
> not modified.

Or with the running system.

> 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.

Except that the running system can already do it and doesn't require the 
live system.

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

I was mistaken about what you implied.

You are correct but boot time verification is also possible with the 
running system.

Because they cannot now change the verification code.

> 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.

Yes I agree.

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

I thought that's what you implied.