From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading)
Date: Sun, 3 Aug 2008 14:08:33 +0200 [thread overview]
Message-ID: <20080803120833.GA4302@thorin> (raw)
In-Reply-To: <489591FF.3070601@isaac.cedarswampstudios.org>
On Sun, Aug 03, 2008 at 07:09:51AM -0400, Isaac Dupree wrote:
>
> 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?
biosdisk prefers hard disks over floppies. Of course, usb drives are generally
identified as hard disks, but this problem will go away when we get rid of the
BIOS and access devices directly.
Then again, on BIOS we only use UUIDs when the situation is desperate, like on
a cross-disk install. If you're concerned about security and/or reliability,
don't do cross-disk installs.
> (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?
This line of thinking is what is commonly used to justify draconian measures
(i.e. Treacherous Computing) but it doesn't make any sense. If your security
policy is such that you don't trust users with physical access, try any of
the following:
- Crypt your whole disk. Have your /boot in a usb drive you carry with you.
- Remove your CD drive and unexpose USB slots (use locks or if really paranoid
sink your board in concrete).
So-called "Trusted" Computing is just a blatant excuse to steal your music and
your documents. Don't drink the kool aid.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
next prev parent reply other threads:[~2008-08-03 12:09 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-22 13:34 Issue with boot != root and chainloading Andy Kittner
2008-07-22 13:50 ` Pavel Roskin
2008-07-22 14:01 ` Felix Zielcke
2008-07-22 23:58 ` Pavel Roskin
2008-07-24 9:12 ` Felix Zielcke
2008-07-24 10:25 ` Felix Zielcke
2008-07-24 11:00 ` Felix Zielcke
2008-07-24 16:49 ` Pavel Roskin
2008-07-25 21:08 ` Robert Millan
2008-07-25 21:47 ` Pavel Roskin
2008-07-25 22:10 ` [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading) Robert Millan
2008-07-26 1:08 ` Pavel Roskin
2008-07-27 12:19 ` Robert Millan
2008-07-27 16:29 ` Pavel Roskin
2008-07-27 18:37 ` Robert Millan
2008-07-27 19:28 ` UUID boot on ieee1275 (Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading)) Robert Millan
2008-07-27 20:13 ` [PATCH] " Robert Millan
2008-07-27 20:36 ` Robert Millan
2008-07-30 10:41 ` Robert Millan
2008-08-03 11:09 ` [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading) Isaac Dupree
2008-08-03 12:08 ` Robert Millan [this message]
2008-08-03 12:23 ` Robert Millan
2008-08-03 17:04 ` Isaac Dupree
2008-08-03 19:19 ` Treacherous Computing (Re: [PATCH] use UUIDs for cross-disk installs) Robert Millan
2008-07-27 18:27 ` [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading) Robert Millan
2008-07-30 10:43 ` Robert Millan
2008-07-22 15:09 ` Issue with boot != root and chainloading Andy Kittner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080803120833.GA4302@thorin \
--to=rmh@aybabtu.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.