Re: [PATCH] use UUIDs for cross-disk installs (Re: Issue with boot != root and chainloading)

[Isaac Dupree]

Robert Millan wrote:
> 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.

that's good

> 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

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!

> try any of
> the following:
>
>   - Crypt your whole disk.  Have your /boot in a usb drive you carry with you.

(well, I do crypt my home-directory with LUKS and a long 
random password made with physical dice, which would be a 
decent way of keeping someone who steals my computer from 
reading/changing my documents, except that I hardly ever 
shut down my computer.  Besides that LUKS password, and my 
very short login passwords, my computer trusts the 
user-with-physical-access completely.)

>   - Remove your CD drive and unexpose USB slots (use locks or if really paranoid
>     sink your board in concrete).

Hehe, those are completely unnecessary, me choosing "don't 
ever insert CD or USB" is quite sufficient.  I trust myself 
even when I don't trust my computer to do what I naively 
believe it should do.  But never inserting CD/USB makes it 
infinitely harder for me to use CD/USB! (for innocuous data 
purposes -- I tend to assume that data can't have viruses in 
it because Linux programs aren't very buggy, which is 
perhaps a foolish assumption.  But it's in contrast to 
booting something on bare hardware, which requires no 
software bugs (on my hard disk) in order to modify my system.).

> 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 (in my experience, I 
could only trust my computer completely if I knew exactly 
what all software on it was supposed to *do* and it was 
bug-free, because no computer interface in history has been 
perfectly safe and undo-able).  Actually I suppose I was 
describing something a little more subtle: software that 
doesn't trust other software (unless I say so, which is an 
important "unless").  But it's just like in Linux: software 
run as "root" doesn't trust most other software unless I say 
"sudo", which is a tricky way of making sure overly helpful 
user-level software doesn't try to mess with my system 
behind my back; which works because that software doesn't 
think it knows my password.  Luckily, programs don't 
"helpfully" try to memorize my login password, because it's 
obvious to their devs that *that's* insecure, and some 
people have heavier security needs that deserve passwords 
that have significant strength.  "Attacker" is just such a 
convenient description.  Many issues that can be caused by 
an attacker can be caused with somewhat less likelihood by 
mistake or complicated situation, and can be treated as 
ordinary design issues.

Understanding how each computer works, helps; DRM harms.

> 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!)

-Isaac