On 05/31/2012 04:04 PM, Jon Ciesla wrote: > On Thu, May 31, 2012 at 2:57 PM, Jon Ciesla <limburgher@xxxxxxxxx> wrote: >> On Thu, May 31, 2012 at 2:07 PM, Gerry Reno <greno@xxxxxxxxxxx> wrote: >>> On 05/31/2012 02:52 PM, Jon Ciesla wrote: >>>> On Thu, May 31, 2012 at 1:21 PM, Gerry Reno <greno@xxxxxxxxxxx> wrote: >>>>> On 05/31/2012 02:17 PM, Jon Ciesla wrote: >>>>>> On Thu, May 31, 2012 at 1:08 PM, Gerry Reno <greno@xxxxxxxxxxx> wrote: >>>>>>> On 05/31/2012 01:57 PM, Jon Ciesla wrote: >>>>>>>> On Thu, May 31, 2012 at 12:52 PM, Gerry Reno <greno@xxxxxxxxxxx> wrote: >>>>>>>>> On 05/31/2012 01:48 PM, Jon Ciesla wrote: >>>>>>>>>> On Thu, May 31, 2012 at 12:42 PM, Gerry Reno <greno@xxxxxxxxxxx> wrote: >>>>>>>>>>> On 05/31/2012 01:34 PM, Jon Ciesla wrote: >>>>>>>>>>>> On Thu, May 31, 2012 at 12:22 PM, Gerry Reno <greno@xxxxxxxxxxx> wrote: >>>>>>>>>>>>> On 05/31/2012 01:19 PM, Jon Ciesla wrote: >>>>>>>>>>>>>> On Thu, May 31, 2012 at 12:16 PM, Gerry Reno <greno@xxxxxxxxxxx> wrote: >>>>>>>>>>>>>>> On 05/31/2012 01:10 PM, Gregory Maxwell wrote: >>>>>>>>>>>>>>>> On Thu, May 31, 2012 at 1:07 PM, Gerry Reno <greno@xxxxxxxxxxx> 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. . -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
