noauto option ignored in /etc/fstab?

[Josef Wolf]

On Thu, Dec 07, 2017 at 04:44:37PM +0100, Xen wrote:
> 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.

I already had 16.04 running on that system. But about a month ago the disk
died, and after the reinstall onto a new disk this problem arised.

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

It records that the boot was successful in /boot/grub/grubenv:

  root at bu201:/# systemctl status grub-common.service 
  ● grub-common.service - LSB: Record successful boot for GRUB
     Loaded: loaded (/etc/init.d/grub-common; bad; vendor preset: enabled)
     Active: active (exited) since Mo 2017-12-04 10:57:02 CET; 3 days ago
       Docs: man:systemd-sysv-generator(8)
  
  Dez 04 10:57:00 bu201 systemd[1]: Starting LSB: Record successful boot for GRUB...
  Dez 04 10:57:02 bu201 systemd[1]: Started LSB: Record successful boot for GRUB.

                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> Have you already tried disabling unattended-upgrades?

Not yet... But "systemctl status boot.mount" seems to reveal that grub-common
is responsible for the mount.

Is there any way to generate some sort of dependency-tree of systemd
services/mounts? Or is try+error by disabling services+rebooting the only way
to track down such things?


When comparing from before the disk died:

- unattended-upgrades was not changed at all. I can tell for sure, since all
  configuration on my system are done completely automatic.

- But boot process HAS changed. On the original disk, there was EFI enabled
  with windows rescue partition and whatrever. With the new disk, I could not
  get dual-boot working until I disabled this dams EFI thing and went back to
  traditional partition table.

So all the evidence point to grub.

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

Umm... ;-)

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

When the system was powered off, getting into the running encrypted system
means to use (possibly manipulated) grub. So grub needs to be verified outside
the encrypted system, before it can be booted.

That's why a (trusted) live-cd is needed:

1. boot the life-cd
2. unlock+mount the FS that contains the recorded checksums and the
   verification script.
3. run the verification script
4. Only after the verification script shows that there were no manipulation,
   the real system can be booted.

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

???

Why?

The checksums are stored on one of the encrypted partitions right there on the
system. It's just a matter to cryptsetup+mount+verify using a live-cd

After booting the live-cd, I do:

  # cryptsetup luksOpen /dev/sdXX x
  # mount /dev/mapper/x /mnt
  # /mnt/md5log/check

if the script says everything is OK, i can reboot.

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

The whole point of this use case is to boot the system without running manipulated
grub/kernel/initrd/whatever. That's why the system should not be booted before
the verification has been done with the help of some (trusted) live-cd.

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

My assumption is that attacker has physical access. Whether he takes out the
disk or uses a live-cd doesn't make much of a difference.

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

How do you get into a running system without using malicious grub when the
system was powered off? I don't see a way without using a live-cd. Well, you
could use a live-DVD ;-))

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

How would it do that? Assumption is that attacker modifies system when it is
powered off. No running system as a guardian around here.

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

How that?

> Because they cannot now change the verification code.

For sure: as long as the system is running, you're safe against this sort of
attack. This verification is to guard against manipulation of a system which
is powered off. Nothing more. Protecting a running system is a totally
different topic.

-- 
Josef Wolf
jw at raven.inka.de