Fwd: [OLPC Security] Securing the laptop: First pass for some basics.

[Tim Flavin]

---------- Forwarded message ----------
From: Simson Garfinkel <simsong at acm.org>
Date: Jul 11, 2006 4:29 PM
Subject: Re: [OLPC Security] Securing the laptop: First pass for some basics.
To: Tim Flavin <tim.flavin at gmail.com>


Of course we need to trust the BIOS, and I'm not suggesting that we
use trusted hardware. However, there is a middle ground.

I'm interested in your threat model. Not that the system is
compromised, but my question: how did the system become compromised?
Who is trying to compromise it, and why?

Clearly you want to have an integrity checker. Where is it? What
prevents it from being compromised? What does it do when the system
is compromised, but the integrity checker isn't? How is the system
fixed ?

I suggest that some very simple modifications to the BIOS could go a
very long way.


On Jul 11, 2006, at 4:23 PM, Tim Flavin wrote:

> On 7/11/06, Simson Garfinkel <simsong at acm.org> wrote:
>> To continue my posting...
>>
>>
>> It makes a lot of sense to consider "undo" and "redo" features.
>> However, what is your model for how the laptop entered a broken
>> configuration to begin with?
>>         -> If it was a hostile act, then the hostile software
>> would surely
>> have patched, broken, or deleted the backup copies.
>
> I am trying to protect against anything but a compromised BIOS.
> This includes user experiments, accidents, and hostile acts.
> In the worst case you would have to attach a disk to the laptop's
> USB port and boot from it, but the BIOS would be able to verify  the
> integrity of the system it was booting from.  (Modifying the Linux
> BIOS
> will be a later phase of the project.  The first phase is to get an
> AIDE
> like Python script to verify the integrity of the system, and fix
> it if
> necessary.)
>
>>
>> My preferred way of fixing a laptop is to attach it to a known-good
>> laptop using the "target" mode described in my previous message. Boot
>> the broken laptop in target mode, connect with with a USB A -> USB A
>> cable to a known good laptop, and have the known good laptop either:
>>         a. repair the disk
>>         b. reinstall the operating system.
>>         c. wipe the laptop and start over.
>>
>
> Nice if you can do it, but this laptop can't do it.  Even the next
> generation hardware
> will require (trusted) software running on the target laptop.  We can
> do a, b, and c,
> but we have to at least trust the (Linux) BIOS.
>
>>
>> Something else from the post bothered me:
>> >
>> >> Good point.  I was hopeing that there would not be a lot of
>> >> configuration
>> >> files. Hostname and password files would be special cases. Most of
>> >> the other
>> >> files I can think of are .profile type files in /home/*.  We can
>> >> back these
>> >> up and replace them with working default files and let the student
>> >> replace them with the backups. This program is mostly intended to
>> >> help
>> >> people who don't edit a lot of files in /etc.
>>
>>
>> I realize that most of the people working at Laptop eat and breathe
>> Unix, but do you really think that it's a good idea to have .profile
>> files?  I think that it makes a of sense to do away with startup and
>> configuration files as much as possible.
>>
> I do NOT like .profile files.  I want to do away with start up and
> configuration
> files, but in earlier in this thread, Jim G. was not letting me
> ignore them.
> Doing away with start up and configurations files is a great thing,
> but that is
> a different project.  I am trying to do an integrity checker that can
> fix problems
> without getting tangled up in configuration files. (Looks like I am
> not doing a
> good job.)  I hope Chris has some good ideas.
>>
>>
> Tim Flavin
>