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

Simson Garfinkel simsong at acm.org
Tue Jul 11 07:57:33 EDT 2006


I'm glad we are finally having some traction on this mailing list.

1. The idea of computing cryptographic checksums and/or digital  
signatures on the computer's packages makes a lot of sense. Are you  
proposing to do this at the time of installation, at boot, or before  
each program is run?

	-> If it is done at installation time, then you should use the  
existing Linux RPM-signing system.
	-> If it is done at boot time, what precisely is the purpose?
		What are you going to do if the check fails ?
		What is your threat model? That somebody has patched the binary but  
has not also patched the binary-verification-binary? Is this likely?
		There are already root kits that allow one version of a program to  
be accessed for read() system calls and another version to be  
accessed for exec() system calls. Given the existence of these root  
kits, attempting to detect changes after the fact seems hopeless.
	-> If the binary is verified at run time, again, what is the  
purpose? What will you do if the verification fails?

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.
	-> 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.

More later; I'm on a plane...

On Jul 11, 2006, at 12:12 AM, Christopher Blizzard wrote:

> Tim Flavin wrote:
>>>
>>> > Instead of generating
>>> > cryptographic checksums from the files on the laptop,
>>> > the checksums would be contained in files cryptographically
>>> > signed by the school districts and schools.
>>>
>>> Linux packaging generally has check sums files in packages that  
>>> allow
>>> you to do verification, and digital signatures on the packages
>>> themselves.
>> The problem with packages is that you have to check the signiture on
>> each one of hundreds if not thousands of packages before you can  
>> trust
>> the checksums. Verifing signatures is compute and in our case power
>> intensive.
>
> We could make this a lot faster.  The reason why we end up  
> checksumming every file in every package is because every package  
> is separate and it's nice to be able to tell users what file has  
> been changed.  But those aren't necessarily our goals.
>
> What you could do is have a manifest of files and run a single  
> md5sum on that set based on a well-known algorithm to get the files  
> in the right order.  That way you can tell that something has gone  
> wrong in a particular set, and you can probably use that  
> information to track down which files has changed using an offline  
> database.
>
>> This program would run in several modes.  The beginner could use  
>> it to fix
>> problems get his laptop back in working order.  This would be the
>> equivalent of a
>> partial reload.  For more advanced students, it can flag the files  
>> and let
>> them decide what to do.
>> My basic aim is to be able to quickly see if the system is OK and  
>> give a
>> "FIX IT" button to inexperienced user.  (We may have a lot of them  
>> soon.)
>
> Like a big "Undo" button? :)
>
> I would love this as well.  What do you use for a source?  Another  
> laptop?  Some server?  (Which won't always be there?)
>
>> 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.
>
> My personal goal is to take the system files from one machine and  
> clone them to another and have them "just work."  This means that  
> config files really do need to be transitory.  That is, you never  
> have to change a system config file in order to do something to  
> your system.
>
> --Chris
>
> _______________________________________________
> Security mailing list
> Security at laptop.org
> http://mailman.laptop.org/mailman/listinfo/security
>



More information about the Security mailing list