noauto option ignored in /etc/fstab?
list at xenhideout.nl
Thu Dec 7 23:14:54 UTC 2017
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:
> Active: active (exited) since Mo 2017-12-04 10:57:02 CET; 3 days
> Docs: man:systemd-sysv-generator(8)
Right, I guess I should have read your other emails with more
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
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
> 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
> means to use (possibly manipulated) grub. So grub needs to be verified
> 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
luksOpen is not required though, open will do fine.
> The whole point of this use case is to boot the system without running
> grub/kernel/initrd/whatever. That's why the system should not be booted
> 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
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
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
> 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
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
> 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
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
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
But anyway, I'll stop.
More information about the ubuntu-users