noauto option ignored in /etc/fstab?

[Josef Wolf]

On Fri, Dec 08, 2017 at 12:14:54AM +0100, Xen wrote:
> Josef Wolf schreef op 07-12-2017 18:55:
> 
> >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)
> 
> Right, I guess I should have read your other emails with more attention...
> 
> Grub-common.service does not pull in the mount, but I guess it happens
> because of "auto" ?
> 
> >Is there any way to generate some sort of dependency-tree of systemd
> >services/mounts?
> 
> The listing I gave you before resulted from "systemd-analyze dot".

Ah! Now THAT'S a really useful information:

  root at bu201:/# systemd-analyze dot |grep boot
        "umount.target"->"boot.mount" [color="green"];
        "local-fs.target"->"boot.mount" [color="green"];
        "boot.mount"->"system.slice" [color="green"];
        "boot.mount"->"local-fs-pre.target" [color="green"];
        "boot.mount"->"systemd-fsck at dev-disk-by\x2duuid-2b61601c\x2d84d6\x2d47a5\x2d80eb\x2d9149ce116be8.service"[color="green"];
        "boot.mount"->"dev-sda5.device" [color="green"];
        "boot.mount"->"systemd-journald.socket" [color="green"];
        "boot.mount"->"-.mount" [color="green"];
        "boot.mount"->"systemd-fsck at dev-disk-by\x2duuid-2b61601c\x2d84d6\x2d47a5\x2d80eb\x2d9149ce116be8.service"[color="black"];
        "boot.mount"->"system.slice" [color="black"];
        "boot.mount"->"-.mount" [color="black"];
        "boot.mount"->"umount.target" [color="red"];
        "dev-sda5.device"->"boot.mount" [color="grey66"];
        "unattended-upgrades.service"->"boot.mount" [color="green"];
        "unattended-upgrades.service"->"boot.mount" [color="black"];
   Color legend: black     = Requires
                 dark blue = Requisite
                 dark grey = Wants
                 red       = Conflicts
                 green     = After
  root at bu201:/# 

Looks like unattended-upgrades.service and local-fs.target are pulling
boot.mount?


So I've executed "systemctl disable unattended-upgrades.service" and now /boot
is no longer mounted after reboot.

So you were right all the time. I was mislead by grub's log entries.

Guess, I should file a bug against unattended-upgrades package, since
/lib/systemd/system/unattended-upgrades.service is part of this package?



Now, how would I run unattended-upgrades manually?

/lib/systemd/system/unattended-upgrades.service only has an ExecStop entry,
but no Exec entry.

Is it OK to run /usr/bin/unattended-upgrade directly from cron?

> >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.
> 
> I guess your use case resolves around the possibility that someone might
> intrude the user directly after booting.

No. It resolves the possibility that someone would mess with your laptop when
it is powered off at home while you're at work.

> >After booting the live-cd, I do:
> >
> >  # cryptsetup luksOpen /dev/sdXX x
> >  # mount /dev/mapper/x /mnt
> >  # /mnt/md5log/check
> 
> That's (for me) a lot of manual work each time you would want to boot the
> system.

Depends how often you boot. Myself usually boots only when some upgrade tells
me that a reboot is required.

> luksOpen is not required though, open will do fine.

Good to know! I always hated those camel-case keywords. How on earth can
someone come up with such braindead camel-case keywords for the command line?

> >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.
> 
> I understand it just seems undoable this way.

???

> Do you realize you could probably burn Grub to a CD and then boot from the
> CD?

I know.

But this has two disadvantages:
1. I would have to maintain my own boot-cd instead of just using one of the
   billions of already existing live-cd.
2. I would need the cd on every boot. With the current setup, I can safely
   skip the verification step when I know for sure that nobody had physical
   access to the laptop during the power-off. For example for a quick reboot
   or something.

> And you probably have something that boots a little faster than Ubuntu'(s)

No. I just don't boot that often. Granted, the days when uptimes were measured
in years are long gone. But we still don't need to boot on a daily basis.

> >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.
> 
> I implied that BIOSes can be password protected to not allow booting from
> other media, but I won't argue about your use case.

BIOS protection won't prevent an attacker to take out the disk for a
manipulation.

I want to catch EVERY manipulation. No matter which method the attacker would
invent.

> No I meant that I was not considering a high-risk situation in which
> directly after booting you could get compromised.

The compromise needs not to take place directly after the boot. The attacker
can wait until you're at work again.

> Of course it would be extremely hard to immediately trace the location where
> the modified grub would have written its data,

It could even have been sent over the net.

> although someone knowledgeable enough could immediately automate this step
> (run some virtual environment and execute the boot code there and then
> verify what it's done) -- but this doesn't make the whole setup easier.
> 
> However you would defeat any attacker.
> 
> You could immediately verify grub while in the initrd and take measures, but
> it would have to be automated.

Malicious grub can restore original grub once it has harvested your password.

I don't see how you would get a reliable solution without verifying BEFORE
executing.

> No I meant that you would know after the fact that Grub had been modified.

Once you executed malicious code, you've lost. That's because you never know
what the code might have done.

Malicious grub could send your PW over the net and restore the original disk
contents that the attacker stored somewhere on the net. Then it continues the
boot as usual. Your verification would not notice any changes.

-- 
Josef Wolf
jw at raven.inka.de