Re: [RFC] Second attempt at kernel secure boot support

[Eric Paris]

On Thu, Nov 1, 2012 at 10:42 AM, James Bottomley
<James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On Thu, 2012-11-01 at 10:29 -0400, Eric Paris wrote:
>> On Thu, Nov 1, 2012 at 5:59 AM, James Bottomley
>> <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
>>
>> > But that doesn't really help me: untrusted root is an oxymoron.
>>
>> Imagine you run windows and you've never heard of Linux.  You like
>> that only windows kernels can boot on your box and not those mean
>> nasty hacked up malware kernels.  Now some attacker manages to take
>> over your box because you clicked on that executable for young models
>> in skimpy bathing suits.  That executable rewrote your bootloader to
>> launch a very small carefully crafted Linux environment.  This
>> environment does nothing but launch a perfectly valid signed Linux
>> kernel, which gets a Windows environment all ready to launch after
>> resume and goes to sleep.  Now you have to hit the power button twice
>> every time you turn on your computer, weird, but Windows comes up, and
>> secureboot is still on, so you must be safe!
>
> So you're going back to the root exploit problem?  I thought that was
> debunked a few emails ago in the thread?
>
> Your attack vector isn't plausible because for the suspend attack to
> work, the box actually has to be running Linux by default ... I think
> the admin of that box might notice if it suddenly started running
> windows ...

Maybe you misread.  The owner of the box would never know a shim Linux
was loaded.  In any case, as I said, windows really is irrelevant.
It's just using Linux as an attack vectore against Windows is what
would get keys revoked.  If your key is revoke Linux can't boot on a
large amount of new hardware without BIOS twiddling.u

>> In this case we have a completely 'untrusted' root inside Linux.  From
>> the user PoV root and Linux are both malware.  Notice the EXACT same
>> attack would work launching rootkit'd Linux from Linux.  So don't
>> pretend not to care about Windows.  It's just that launching malware
>> Linux seems like a reason to get your key revoked.  We don't want
>> signed code which can be used as an attack vector on ourselves or on
>> others.
>>
>> That make sense?
>
> Not really, no.  A windows attack vector is a pointless abstraction
> because we're talking about securing Linux and your vector requires a
> Linux attack for the windows compromise ... let's try to keep on point
> to how we're using this feature to secure Linux.

I pointed out that the exact same attack exists with Linux on Linux.
To launch a malware linux kernel all you have to do is launch a shim
signed acceptable linux environment, have it set up the malware kernel
to launch after resume, and go to sleep.  Agreed, it'd be very weird
that the first time you hit the power button your machine comes on and
then quickly goes right back to sleep, but certainly we can envision
that being ignored by many desktop users...

Do you see how 'root' in the first environment is untrusted?  Now you
can pretend not to care because the 'original' root was trusted.  But
people install bad crap all the time.  There are hundreds of ways to
install bad software as root.  Go to any site distributing rpms or
debs to get that new version of mod_perl and it could install the
malware kernel and shim environment.

The point of secureboot is even if the admin did something which
allowed his kernel to be compromised, it won't persist.  Sure,
secureboot moves the attack up the stack to userspace, but at least we
can do something about the kernel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/