On Thu, May 31, 2012 at 2:57 PM, Jon Ciesla
<limburgher(a)gmail.com> wrote:
> On Thu, May 31, 2012 at 2:07 PM, Gerry Reno <greno(a)verizon.net> wrote:
>> On 05/31/2012 02:52 PM, Jon Ciesla wrote:
>>> On Thu, May 31, 2012 at 1:21 PM, Gerry Reno <greno(a)verizon.net> wrote:
>>>> On 05/31/2012 02:17 PM, Jon Ciesla wrote:
>>>>> On Thu, May 31, 2012 at 1:08 PM, Gerry Reno <greno(a)verizon.net>
wrote:
>>>>>> On 05/31/2012 01:57 PM, Jon Ciesla wrote:
>>>>>>> On Thu, May 31, 2012 at 12:52 PM, Gerry Reno
<greno(a)verizon.net> wrote:
>>>>>>>> On 05/31/2012 01:48 PM, Jon Ciesla wrote:
>>>>>>>>> On Thu, May 31, 2012 at 12:42 PM, Gerry Reno
<greno(a)verizon.net> wrote:
>>>>>>>>>> On 05/31/2012 01:34 PM, Jon Ciesla wrote:
>>>>>>>>>>> On Thu, May 31, 2012 at 12:22 PM, Gerry Reno
<greno(a)verizon.net> wrote:
>>>>>>>>>>>> On 05/31/2012 01:19 PM, Jon Ciesla
wrote:
>>>>>>>>>>>>> On Thu, May 31, 2012 at 12:16 PM,
Gerry Reno <greno(a)verizon.net> wrote:
>>>>>>>>>>>>>> On 05/31/2012 01:10 PM, Gregory
Maxwell wrote:
>>>>>>>>>>>>>>> On Thu, May 31, 2012 at 1:07
PM, Gerry Reno <greno(a)verizon.net> wrote:
>>>>>>>>>>>>>>>> Could be any of a
thousand ways to implement this.
>>>>>>>>>>>>>>>> Maybe it checks the BIOS
to determine whether some SecureBoot flag is set.
>>>>>>>>>>>>>>> While it pains me to argue
with someone on my side— you're incorrect.
>>>>>>>>>>>>>>> The compromised system would
just intercept and emulate or patch out that test.
>>>>>>>>>>>>>> Then what's missing here is a
way for booted OS's to test themselves for integrity.
>>>>>>>>>>>>> Maybe some sort of cryptographic
signature stored in the hardware?
>>>>>>>>>>>>>
>>>>>>>>>>>>> <ducks>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -J
>>>>>>>>>>>>>
>>>>>>>>>>>>> </sarcasm>
>>>>>>>>>>>>>
>>>>>>>>>>>> Just not dictated by one monopoly.
>>>>>>>>>>> Ideally, no. But you see the problem.
I'm divided on the solution
>>>>>>>>>>> myself, but I've yet to see one I feel
better about.
>>>>>>>>>>>
>>>>>>>>>>> -J
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> This game of cat and mouse with the blackhats is
not going to end until we have some type of read-only partitions where
>>>>>>>>>> known good code resides.
>>>>>>>>> We have that, ISO9660. Known good == known good to
whom?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> Nah, can't be iso.
>>>>>>>>
>>>>>>>> Has to be HDD partitions whose ro/rw state is controlled
by hardware.
>>>>>>> Which brings us back to the issue of how the hardware knows
what to
>>>>>>> trust for that ro/rw state.
>>>>>> The hardware is under control of the user.
>>>>>>
>>>>>> At some point the user has to know what they consider trusted.
>>>>>>
>>>>>> During installation from a known good installation source: DVD,
network, whatever, the user enables the install to write
>>>>>> on the partition by actively pressing a hardware button that
allows the write. After the installation is finished the
>>>>>> user switches it back to read-only through pressing the hardware
button.
>>>>>>
>>>>>> The user now has a known good read-only installation to boot
from.
>>>>> Is there an implementation of this existing today for HDD?
>>>> Not yet. But HDD technology is changing rapidly. Just look at hybrid
drives, SSD.
>>>>
>>>> No reason they could not add this capability.
>>> Right. But it's not there now, which is my point.
>> Actually it seems the forensic firms have been doing this for a while:
>>
>>
http://www.digitalintelligence.com/forensicwriteblockers.php
>>
>> Their interfaces toggle the write wire to the drive.
> But that's not currently available COTS hardware.
>
>>>>> Because
>>>>> otherwise with existing technology, AFAIK, that limits your media
>>>>> choices for root fs medium to CD/DVD-R, Floppy, Zip/Jaz disc, or
some
>>>>> models of USB flash drive.
>>>> Yes, all these would currently support what I'm suggesting.
>>> Actually, if you're willing to flip a lot of switches, you could
>>> probably make your / a raid5 of floppies, but the performance would be
>>> suboptimal.
>>>
>>> -J
>>>
>> Ok, now you're just being silly.
> Absolutely.
And to clarify, I was being silly to illustrate that what we're after
cannot be practically done with currently available hardware.
-J
Hmm... Yes, but neither can Secure Boot.
And I'd rather see a User-Controlled implementation rather than a Monopoly-Controlled
implementation.
.