noauto option ignored in /etc/fstab?

[Xen]

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

You are supposed to feed this to a program but you can read the 
dependencies directly.

> So all the evidence point to grub.

The strange thing is still that the grub service 
(/run/systemd/generator.late/grub-common.service) does not pull in /boot 
on my system.

Which I guess you already found.


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

> 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

That's (for me) a lot of manual work each time you would want to boot 
the system.

luksOpen is not required though, open will do fine.

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

Well I don't know about your use case really, if it is more than the 
development of a model so to speak.

Of course live CDs require no setup...

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

In general though you can install Grub anywhere.

Well I guess I am trying to tell you alternatives instead of telling you 
the answer to your question.

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

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

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

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

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.

For instance you could immediately verify and restore any 
inter-partition areas but there is plenty of space elsewhere including 
the encrypted partition itself.

The code could even select a random location to write to.

Nevertheless if all else failed you could even immediately destroy the 
master key, but that is not a very attractive situation; on the other 
hand you could store a copy somewhere else.

I guess your position is to be better safe than sorry.

The attacker would still have your password which may not be pleasant 
either.

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

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

Knowing this you could run verification code on the entire harddisk, but 
although you could safeguard inter-partition areas this way, there is no 
way you would be able to verify encrypted areas, as the likelyhood of 
someone overwriting existing data and you noticing it would be rather 
small.

Nevertheless you would make it rather hard for the attacker; but running 
such code might take time as well.

However you now only have the MBR, the grub core module, and one 
partition, which is encrypted.

There is no space beyond the first megabyte which is not encrypted.

So if your code verifies the first and the last (10) megabytes, and if 
you even leave, in your LVM, some empty space at the end,

it is becoming rather difficult for the attacker to write anything 
anywhere that you couldn't immediately wipe, other than some EFI 
variables or something similar.

The problem is that it might take your system time to discover this area 
and you might not have that time I guess.

But it's becoming very difficult for the attacker to reliably write 
something somewhere that wouldn't overwrite something, and I guess a 
tool like Aide or YASAT does what you are already doing... but I mean 
unless they already knew your partition layout in advance.

Partitions usually start on megabyte boundaries and in LVM it is going 
to be rather predictable where they start (also thinking for myself) and 
hence where the filesystems commence and where the alignment of the data 
areas is going to be...

But using the harddisk for storage becomes a risky enterprise for the 
attacker...

But anyway, I'll stop.