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

Tim Flavin tim.flavin at gmail.com
Sat Jul 15 22:51:53 EDT 2006


---------- Forwarded message ----------
From: Simson Garfinkel
Date: Jul 11, 2006 3:43 PM
Subject: Re: [OLPC Security] Securing the laptop: First pass for some basics.
To: Tim Flavin



On Jul 11, 2006, at 3:06 PM, Tim Flavin wrote:

> On 7/11/06, Simson Garfinkel  wrote:
>
>> I think that it makes sense to:
>>         -> Verify the programs at time of install.
>>         -> Have an option that allows the computer to "verify
>> itself," but
>> don't run it on a regular basis.
>
> I was thinking the student would want to do this about once a week
> when he was at school and had access to a server with backup files,
> and whenever his laptop was miss-behaving. (This is being optimistic,
> most people, including me, don't integrity check their systems this
> often, if ever.)

Hi, Tim. You replied just to me.  Is this intentional?

Why would there be a reason to refresh the machine every week? That
seems very high-overhead and not in line with typical computer use.

This usage is something that certainly could be done, but I doubt
that it would be done. I think that we need to focus on usable security.


>
>>         -> Have an option that allows one computer to verify another
>> computer. The second computer runs in some sort of "slave" mode (like
>> booting a Mac with the T key held down to put it in target mode.)
>> The root kit etc. on the second computer won't have a chance to run
>> in this configuration.
>>
>
> I don't think the laptop has the hardware to permit this.  It does
> have a
> write protected BIOS.  (It can be manually write-enabled at boot,
> and what
> I am discussing does not protect against a modified BIOS.)  I was
> proposing
> that the Linux BIOS be able to do an integrity check of the regular
> kernel and initrd, and
> that they be able to verify the rest of the system.

Target mode could easily be put into the BIOS and, frankly, I think
it should be.

I agree with a verification-at-boot is potentially useful. But once
again, rather than engineering by nice-to-haves, I think that it's
better to engineer with a specific threat model in mind.

>


More information about the Security mailing list