*countable infinities only

[Gerry Reno]

On 05/31/2012 04:04 PM, Jon Ciesla wrote:
> On Thu, May 31, 2012 at 2:57 PM, Jon Ciesla <limburgher at gmail.com> wrote:
>> On Thu, May 31, 2012 at 2:07 PM, Gerry Reno <greno at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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.

.