[conspire] (forw) Re: [Felton LUG] Oh boy, this doesn't look good...

[Rick Moen]

Quoting Ruben Safir (ruben at mrbrklyn.com):

> It is not self evident because when you apply a logical model to prblem,
> adding cryptokeys fails to alter the logic or the function.

Is it impossible that code on your system under the control of a hostile
party might escalate to root authority and do undesirable things to your
boot chain?  The correct answer to that question is 'no' (i.e., it is
indeed possible).  I know this because I am, y'know, a senior system
administrator.

Having one's boot chain cryptographically verified makes that class of
attack vector not work.  Ergo, self-evident advantage.  Quod erat
demonstrandum.

This is not difficult to understand.  I should not have to explain it to
you.

> the individual who controls the root account controlls the access to the
> cryptopassword...
> nothing is gained.

Your continual repetition of that claim doesn't render it correct.

Read the explanation again as required, until you understand it.  It's
really not difficult.

> The only thing that is gained is that someone OTHER than the human who
> controls root can control the crypto chain, but that is not security, 
> that is a business and extrotion model.

This statement is obviously not correct, and moreover paranoid.  Once a
bootloader is signed, nobody other than the local administrator controls
the boot chain.

I detest the UEFI Secre Boot implementation, and decline to use it.  But
your claim that it (and any less-sucky implementation of the basic
concept) doesn't have a security advantage to the local admin is just
plain wrong.  Just because MSFT does something, and it's undesirable to
use for various reasons, and it is a pain in the neck, doesn't render
it, let alone better implementations of the idea, less than advantageous
by nature.