Robert Millan wrote:
Perhaps we are over-engineering a bit here. In the long run, maybe it makes
more sense to always use UUIDs and drop the make_install_device() complexity.
I'm also concerned that UUID may not be unique. For instance, a disk
was cloned, and a filesystem of the clone was modified without changing
the UUID.
I think in the long term the solution to that is that cloning software
becomes UUID-aware and picks the right option between generating or copying
the UUIDs (of course, the right option could just be what the user says!
but this is outside of our scope ;-)).
Is using UUIDs alone resilient
against this situation:
An attacker finds out the
UUIDs on your hard-disk. S/he
makes a USB drive or CD (that
preferably looks innocuous
when plugged into a running
system), but has a UUID on it
equal to that of the GRUB boot
partition (which might not be
mounted on a running system).
Anyway, when the system
(core.img) boots, can it tell
the difference well enough to
prefer the GRUB that's on the
disk that it was originally
installed to? (Equally well,
you could have a GRUB core.img
and /boot on a CD or
unwriteable USB drive that
you're trying to boot when you
don't entirely trust the
computer's hard disk.)
Furthermore, perhaps all the
modules that the attacker
provided are the same as the
genuine ones; only grub.cfg
differs... only the most
paranoid of us would try to
put a hash in core.img that
complains whenever grub.cfg
has changed from the original
state?
To try to answer my own
questions: If it's BIOS-based
and a same-drive install (and
if we trust the BIOS, and it's
not too buggy...), and the
BIOS has started booting from
our drive, then we should be
able to check the same drive
first? But if we don't
understand anything about how
the boot-process selected us
to boot, or if it's a
cross-drive install, then
there's no way for us to tell
the difference between "our
disk" and a malicious
duplication of the disk with a
few modifications? Maybe by
interface type (e.g. we
expected it to be on an ATA
not a USB drive)??
I'm sure I might be way off
track, but I worry about the
predictability of my bootloader..
-Isaac
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
