From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Treacherous Computing (Re: [PATCH] use UUIDs for cross-disk installs)
Date: Sun, 3 Aug 2008 21:19:40 +0200 [thread overview]
Message-ID: <20080803191940.GA11728@thorin> (raw)
In-Reply-To: <4895E505.9070303@isaac.cedarswampstudios.org>
On Sun, Aug 03, 2008 at 01:04:05PM -0400, Isaac Dupree wrote:
>
> I'm actually a little more worried about the combination of
> overworked/confused sysadmins making mistakes, and GRUB
> (potentially) not being completely deterministic in the face
> of additional drives (which is inherently confusing because
> it rarely matters). And some of my situations are
> hit-or-miss anyway: if you (the intrepid user trying to boot
> from CD) don't even trust the contents of the hard disk,
> most likely the BIOS or boot process could be corrupted too.
> I suppose I haven't yet seen any duplicate UUIDs, even
> including FAT ids, so I shouldn't worry so much.
>
> Anyway, I *don't* wish to trust the random CDs and USB
> drives I plug in without my explicit say-so, and that's been
> true at least on the Mac for years and years before TPM
> chips became common, probably even before CDs became common.
> The point is that giving my explicit say-so is easy. The
> way I interpret that in the case of a bootloader that's not
> built in but that's on one of the drives, is that GRUB only
> trusts the drive it's on (and the RAM, CPU etc.) by default,
> or whatever configuration of hardware you want to specify
> allowing in grub.cfg? (Or maybe just a well-defined search
> order is sufficient -- but it would be odd to find something
> identified by UUID on a different disk than it was
> originally, so the user might want to be asked if all is as
> s/he intended.) Of course at GRUB commandline you can still
> boot from CD! Locking away GRUB's powers from its user is a
> completely different matter!
I see. Well I think the answer to your questions will be when we stop
reliing on BIOS completely and use Coreboot/GRUB.
> >So-called "Trusted" Computing is just a blatant excuse to steal your music
> >and
> >your documents. Don't drink the kool aid.
>
> I was a bit worried that my using words like "genuine" and
> "trust" and "attacker" was going to make people think "oh
> no, DRM!", which is when I have software that doesn't trust
> me (eeek!), rather than vice versa
Yeah, I wish we could bring back true meaning of words. It's so
difficult now... :-/
To put it clearly, I think Trusted Computing can be a great idea, but it
basicaly doesn't exist yet. All we have is this treacherous crap they try
to sell as "Trusted" when in fact you don't own your crypto keys and they
pretend (as per spec) to use them as a challenge against you (i.e. sign this
with _our_ key or you're a criminal).
> >Or use a crypto module where you load a key from a secure environment and
> >use
> >that to implement measurement during boot. The TPM could have become such
> >module, but they decided to cripple it by:
> >
> > a) Loading the key themselves.
> > b) Not giving you a copy of the key.
> >
> >I still hope sooner or later a sane company (that is, one that understands
> >basic rights like ownership) will manufacture modules for this purpose.
>
> I suppose (if it existed), that would help tell me whether I
> had actually booted the GRUB that I'd meant to boot. But I
> don't understand how hardware-level encryption works well
> enough. (Anyway, from everything I've heard about its
> special capabilities, it can't even detect when the
> inevitable security flaws in the software you're using are
> being exploited! kaboom, any assumptions about what that
> means for the system's state go out the window!)
Of course. The whole point is not to make your software secure, but to
redefine the security model.
By default (the Universe was made this way), the security model is that
physical access is the root of trust. If you have physical access your
computer "trusts" you as you can make it do anything you want.
Inserting an unbreakable chip can change this model, making it possible for
the owner to be someone without physical control. Of course, this could be
desireable when the user is not the legitimate owner of the device (e.g. a
voting machine), but they designed the scheme in a way (no procedure for key
retrieval, etc) that even the legitimate owner can be excluded from accessing
the root of trust, turning the whole thing into a parody of what security
means for users.
--
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 19:20 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
2008-08-03 12:23 ` Robert Millan
2008-08-03 17:04 ` Isaac Dupree
2008-08-03 19:19 ` Robert Millan [this message]
2008-07-27 18:27 ` 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=20080803191940.GA11728@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.