grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != ro


From: Isaac Dupree
Subject: Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading)
Date: Sun, 03 Aug 2008 07:09:51 -0400
User-agent: Thunderbird 2.0.0.16 (X11/20080724)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]