From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-user+bounces-138885-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1Sbg2U-0002XC-6u
for garchives@archives.gentoo.org; Mon, 04 Jun 2012 22:46:18 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 9174BE0AF4;
Mon, 4 Jun 2012 22:46:04 +0000 (UTC)
Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53])
by pigeon.gentoo.org (Postfix) with ESMTP id 59EFBE09B1
for <gentoo-user@lists.gentoo.org>; Mon, 4 Jun 2012 22:44:30 +0000 (UTC)
Received: by bkcjk13 with SMTP id jk13so4647493bkc.40
for <gentoo-user@lists.gentoo.org>; Mon, 04 Jun 2012 15:44:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type:content-transfer-encoding;
bh=/flWkQ9JLUM5L/nnTso9VfogD+o3HJ4IHBS7LXg3hcY=;
b=SjyPVbQ55dCS7V/HTrGnugcgC2mdZyhMFFE6nixLdiPuSJAtVpc+4ANCeTSBSjlZIz
OxVshkbPFzxbeSktqZ5mQYuVKXI1jZ07FGXBbcWqlxy8pndnALBt49675yPfJlfEvJqg
zl7sWuCr2vvlDwaeay5C1UfFDv7nb2Q8rAyvar/Yn1fsuBel1xzSH1yE6/OmBT4RR4Tl
jEnKFIyJ+UtNfl+eKnuWkCYjSQgrN3LUGJGWY77lODeap24Q1NzzvrO/n0lEhQjLuWmF
jWy53b9k5kBxOqA7gU2J9ry4nvDvZuuanHAPDO7rMWyieF+h42A/kv09zSPQxuWOXb+j
X1vA==
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.204.151.82 with SMTP id b18mr7798744bkw.132.1338849869366;
Mon, 04 Jun 2012 15:44:29 -0700 (PDT)
Received: by 10.204.42.207 with HTTP; Mon, 4 Jun 2012 15:44:29 -0700 (PDT)
In-Reply-To: <1338844421.42836.YahooMailNeo@web39305.mail.mud.yahoo.com>
References: <1338603963.12172.1.camel@moriah>
<4FC9C425.9010301@binarywings.net>
<CA+czFiDWEU3sS+ufDQYTJq-5MZGXW+5008=Cu7RaD2dWjOBZpw@mail.gmail.com>
<4FCA1159.40909@binarywings.net>
<4FCA6EDB.4070908@coolmail.se>
<CA+czFiD2aHPJu2d3P3zuZWKs2mZSxuR0Pfk3w2xZX=k=Uw1o9A@mail.gmail.com>
<4FCA98D2.7020804@coolmail.se>
<CA+czFiBvLvnVY3ASs6BnLywREGEnkUs7QU-Q6H5ouaLV=mzPKw@mail.gmail.com>
<4FCAB160.9040706@binarywings.net>
<CA+czFiBSFZvEFKohW-01Wz+ZbENs21yUQ64QFqnNKHR30KZd+Q@mail.gmail.com>
<1338689084.67744.YahooMailNeo@web39302.mail.mud.yahoo.com>
<CA+czFiD-g4f+SKFqtef164Vde8U=bvH7hD2B_BNJqJcr5W1xsg@mail.gmail.com>
<1338816810.91572.YahooMailNeo@web39302.mail.mud.yahoo.com>
<CA+czFiA-RhmKtaJC=azuXMJJOLMyOCFSAEYtj0sSSE3LH+A3Fw@mail.gmail.com>
<1338844421.42836.YahooMailNeo@web39305.mail.mud.yahoo.com>
Date: Mon, 4 Jun 2012 18:44:29 -0400
Message-ID: <CA+czFiB=qEKCh_63LT4s+PQMzEEFpd5hg4cHu=pVTSn0_jBjQA@mail.gmail.com>
Subject: Re: [gentoo-user] Lockdown: free/open OS maker pays Microsoft ransom
for the right to boot on users' computers
From: Michael Mol <mikemol@gmail.com>
To: gentoo-user@lists.gentoo.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Archives-Salt: bf953d3d-2228-4c64-bad8-6de24c81382c
X-Archives-Hash: 800549b70d85c7556d068f9a19fdb8fb
On Mon, Jun 4, 2012 at 5:13 PM, BRM <bm_witness@yahoo.com> wrote:
>> From: Michael Mol <mikemol@gmail.com>
>
>>On Mon, Jun 4, 2012 at 9:33 AM, BRM <bm_witness@yahoo.com> wrote:
>>>> From: Michael Mol <mikemol@gmail.com>
>>>
>>>>On Sat, Jun 2, 2012 at 10:04 PM, BRM <bm_witness@yahoo.com> wrote:
>>>>>> From: Michael Mol <mikemol@gmail.com>
[snip]
>>>>> Honestly, I don't expect SecureBoot to last very long.
>>>>> Either MS and the OEMs will be forced to always allow users to disabl=
e it,
>>>>> or they'll be simply drop it - kind of like they did with TPM require=
ments that were
>>>>> talked about 10 years back and never came to fruition.
>>>>
>>>>TPM is still around for organizations which can use them. And,
>>>>honestly, I've been annoyed that they haven't been widespread, nor
>>>>easy to pick up in the aftermarket. (They come with a random number
>>>>generator...just about any HRNG is going to be better than none.)
>>>
>>>
>>> Yes TPM (originally named Palladium) is still around. However its use i=
s almost non-existent.
>>
>>No, TPM wasn't originally named Palladium. TPM was the keystore
>>hardware component of a broader system named Palladium. The TPM is
>>just a keystore and a crypto accelerator, both of which are two things
>>valuable to _everybody_. The massive backlash against Palladium is at
>>least part of why even a generally useful hardware component like the
>>TPM never got distributed. Imagine if the floating-point coprocessor
>>was ditched in x86 because people thought it was a conspiracy=C2=A0 to
>>induce difficult-to-resolve math precision errors from careless use of
>>floating point arithmetic.
>>
>>The part you're worried about is the curtained memory and hardware
>>lockout, which it sounds like Intel is distributing with vPro.
>
>
> TPM, SecureBoot, and Palladium are both beasts which need to be removed.
I'm still confused by your malice toward the TPM. What part of 'crypto
coprocessor' or 'crypto accelerator' doesn't get you thinking about
faster SSH and SSL connection setup and data transfers?
[snip]
>>The nature of those controls stems at least in part from the ability
>>to use other means to maintain an overall security policy. With more
>>tools comes the ability to be more flexible, allowing people to do
>>more convenient convenient things (such as insert a flash drive or CD
>>into a computer) at lower risk (it'll be more difficult to
>>accidentally boot from that flash drive or CD).
>
>
> How often do people accidentally boot from the wrong device?
You know how many Linux install flash drives are floating around? What
about OS install CDs? A curious artifact of both is that they're left
in systems so _frequently_, they're often designed to proceed back to
a disk-based boot after a timeout.
> It's probably more of an issue for USB devices than floppy/CDs any more, =
but still.
The Gentoo 12.1 LiveDVD also has the timeout-and-boot. And it's quite
common for people to leave flash drives plugged into systems over boot
cycles; it's like a portable 'My Documents' folder.
>
> And why destroy people's ability to boot from USB/CD/Floppy?
You're not; you can turn off SecureBoot in BIOS, and then boot from
USB or CD as normal. Though why you'd boot from a floppy on a system
that has SecureBoot, I have no idea. (It's questionable whether
systems shipping SecureBoot will even have floppy controllers...)
Being able to disable SecureBoot is going to be _critical_ for
application of diagnostics, forensics and system repair. And if it
comes down to it, you'll likely be able to get those tools signed,
too.
> Let's not forget this makes it harder for Gentoo (and numerous other dist=
ros and OSes) to go on devices.
Nobody's forgotten that. Now let's not forget how easy it will be to
turn SecureBoot off. You're likely to have a harder time getting
latest-grade RAM functioning in a brand-new new system, what with
timings and gang modes to contend with.
> The user should own and control the device, not a corporate entity (excep=
t where said corporate entity purchased the device in the first place).
Fully concur...and I'm moderately impressed; most people I've seen
argue things like this can't make that distinction.
>>It's for similar reasons the Linux kernel has support for fine-grained
>>access controls; you can grant additional privileges where needed, and
>>reduce the base set of privileges required.
>
>
> Linux has fine grain control because that's what's required for Common Cr=
iteria, and what the NSA implemented for SELinux.
SELinux required it because it was necessary. Linux included SELinux
because it's legitimately useful. Anything legitimately useful for
someone else to keep you out of their stuff is legitimately useful for
you to keep them out of yours.
>>And here's a use case that might seem worthwhile...Say you've got
>>hardware with SecureBoot. Now, you don't run Windows, so you don't
>>care about the UEFI BIOS having Microsoft's key. Instead, you're a
>>Linux guy, and you're very privacy conscious; perhaps you're a
>>security consultant or contractor. Or perhaps you're worried about
>>corporate espionage. Or perhaps you're simply afraid of governments.
>>
>>You can flush Microsoft's key from BIOS and insert your own. Sign your
>>bootloader, kernel and initramfs. Set up your / filesystem to be fully
>>encrypted. And configure things such that if BIOS isn't operating in
>>SecureBoot mode with your key, it won't even mount and decrypt your /
>>filesystem.
>>
>>You've just denied access to any existing forensic tool which would
>>either examine your hard disk or operate as a rootkit. The only thing
>>that's going to get your data is a live inspection of your RAM
>>(tricky! but doable.) or a rubber hose.
>
>
> Or you just pull the hard drive and do the decryption elsewhere.
Decryption is not trivial.
> All it does is lock you out of your own system, and hand the keys to some=
one else.
>
> And, on WinRT approved devices you will not be allowed to change the Keys=
for SecureBoot period (not even corporate IT).
> On x86-based Windows devices you'll be allowed to, but it's only a matter=
of time before Microsoft will try to pull the plug there too.
>
>
>>>>>> What kind of signature is the bootloader checking, anyway?
>>>>> Regardless of the check, it'll never be sufficient.
>>>>Sure; ultimately, all DRM solutions get cracked.
>>>
>>> TPM and SecureBoot will by design fail.
>>
>>Please be aware of the distinction between TPM from Palladium. In
>>fact, you should probably be aware of the distinction between tools
>>and policies, too.
>
>
> That won't resolve the issue.
>
>
>>> We'll see if SecureBoot actually even makes it to market; if it does, e=
xpect some Class Action lawsuits to occur.
>>
>>We'll see. Don't forget _you can turn the thing off_. I expect the
>>lawsuits will come around when the ability to turn the thing off or
>>reconfigure it is removed.
>
>
> As noted, WinRT devices will not allow you to change the keys; they also =
won't allow you to turn off Secure Boot.
If I properly understand what's discussed elsewhere in the thread, the
capability to turn off SecureBoot will be required for Windows 8
certification on x86 hardware. So, again, you _will_ be able to turn
it off.
Sure, that may mean you can't access the WinRT subsystem on Windows
with SecureBoot turned off. But you can still boot Linux. Want to boot
Windows and get WinRT? Turn SecureBoot back on and boot Windows.
Yes, dual-booting is going to be a bigger pain than it already is.
And, honestly, I've never really understood dual-booting; if you spend
a long time in one OS, and a short time in another OS, much (most?) of
the time spend in that secondary OS is going to be spent in updates.
Which makes that secondary OS either very insecure for you, or a very
poor, nigh pointless experience.
> If MS can get SecureBoot out there and keep it enabled, then it's just a =
matter of time before they try to do the same thing to the rest of the plat=
forms.
> So expect the lawsuits to happen if it even gets out to start with.
I did some googling after your repeated mentions of WinRT. From the
look of things, it's going to be hitting ARM as well as x86. ARM is
going to have a rougher time of it, though. Microsoft is being more
aggressive in that market...and no surprise; ARM platforms are eating
Microsoft's lunch--they're where you want to be in the mobile and
low-power markets. I think it unlikely Microsoft's going to succeed,
though; they're late to the game, and old giants (Nokia, RIM) are
collapsing.
--=20
:wq