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

[Tim Flavin]

OOPS... As Simson noticed, I accidentally started hitting reply instead of reply
on my last batch of messages.  I will put the messages back on the list now.
Also my ability to connect to the net is a bit tenuis at times durring
the summer.


---------- Forwarded message ----------
From: Tim Flavin
Date: Jul 11, 2006 2:44 PM
Subject: Re: [OLPC Security] Securing the laptop: First pass for some basics.
To: Christopher Blizzard


On 7/11/06, Christopher Blizzard <blizzard at redhat.com> 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.

The problem that I had with the packages was not with the md5sums but
with the signature.  I thought based on a very little research that
verifying the
signature on the package was a lot more expensive than doing a bunch of md5 or
sha1 hashes on the file.  I want to use a single signed AIDE database
file so that I could
verify the signature once, and use that file to verify the rest of the
security information.

I think MD5 is showing its age, so I was going to go with SHA1.
>
> > 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? :)

Yes, even if the student didn't think he did anything.
>
> I would love this as well.  What do you use for a source?  Another
> laptop?  Some server?  (Which won't always be there?)

What ever is available.  A server at school, a friend's laptop, the
net.  As long as
the file has the right hash etc., it doesn't matter.
>
> > 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.
>

Great, I just could not figure out how to make this work.

> --Chris
>
>