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

[Tim Flavin]

On 5/20/06, Jim Gettys <jg at laptop.org> wrote:
> On Tue, 2006-05-16 at 15:49 -0400, Tim Flavin wrote:
> > There hasn't been much activity on this list, so I will try
> > to start discussion on one aspect of security, securing
> > the laptop from malware.  Jim Gettys and others talked
> > about many of these points before, I am mostly organizing
> > and expanding on them.
> >
> > To insure that the laptop is free of malware, the kernel
> > and most other files should be protected by something
> > similar to Tripwire or AIDE.
>
> Good suggestion: do you want to work on this problem

Yes, so I have been experimenting with AIDE, the OLPC software running
under QEMU and a Python program that uses an AIDE database of the OLPC
system for verification and repair.  (This is my first signifgant python
program, so I am spending a lot of time learning.)

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

What I was suggesting is that the school district load up a system with
all of the basic software: Linux, Shuger, ebook, etc. and run AIDE on it
to generate the intrusion detection database.  Normally the database is
stored offline, which would be hard for the students to do.  Instead the
district signs it just like the RPMs.

This lets the student integrity check his computer more quickly than checking
the packages individually.


> There is still some question on whether we should go the
> conventional packaging route, however.

Have we decided yet.  I like packages for adding option, but I like to just
tar the base system in one big blast.  (Probably some recidivist
tendincy from my past.)

>
> In any case, yes, we have to have checksums for files that are to be
> installed on the machine one way or the other.
>

> > Students
> > would be able to load and execute unsigned software, even
> > the kernel, but it would be flagged and possibly removed
> > when anti-malware software is run.
>
> Flagged yes; removed is less clear.  It may be that the right strategy
> is to backup the kid's files and do a full or partial reinstall if one
> seriously suspects malware.

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

>
> > Some or all of the
> > verification will be optional so that the laptop will boot
> > relatively quickly.  Once a week or so, and whenever things
> > don't look right, a full verification can be done to check
> > the systems integrity. A side benefit of the integrity
> > check would be recovery from accidental misconfiguration.
> > Replacing all files flagged by the integrity check could
> > guarantee a functional laptop.
> >
>
> Actually, while helpful, an integrity check cannot make such guarantees:
> configuration files can get screwed up.

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.

>
> > There would be a hierarchy of signatures and signed
> > files. Revoking the highest level signature would
> > require updating the BIOS in the laptop.  Revoking other
> > signatures would only require updating files on the laptop.
> > The depth of the hierarchy would have to be limited due
> > to the fact that verifying signatures is computationally
> > intensive for a power limited laptop running at 400 Mhz.
>
> I don't know if we need hierarchy, it may be just a list of acceptable
> signatures.

Glad to skip the hierarchy if we don't run into scailing problems.

>
> >
> > In
> > http://mailman.laptop.org/pipermail/security/2006-April/000006.html
> > Jim said:
> > > There is no way to directly write the boot rom from the geode, as I
> > > understand our hardware design.
> >
> > The boot ROM is assumed to be free from malware. Although
> > someone with physical access to the laptop can reprogram
> > the boot ROM, malware executing on the laptop can't
> > compromise the boot ROM.  (If this is not true, we may
> > have a problem.)
>
> We shouldn't have a problem unless a phishing attack has managed to get
> someone to redo the BIOS.  It will require physical intervention to
> enable the write protect.

Good

>
> >
> > The boot ROM contains a small Linux kernel that, at a
> > minimum, can load the fully functional kernel from either
> > the laptop's internal flash disk or a USB flash disk.
> > If there is room in the boot ROM, the boot kernel will be
> > able to load a kernel over WIFI or other media.  Before
> > running the new kernel, the boot kernel will verify it's
> > signature. (The actual verification will probably be done
> > by a program run from initrd which, for this discussion
> > is treated as part of the kernel.)
>
> Remember, we want it to be possible for kids to hack their kernels too.
>
> Our goals here are "easy to fix", and "detect problems that need
> fixing", rather than locking the system down hard.
>

The whole integrity check thing is optional, and can be run in a mode
that just flags differences.  It would be to expensive in time and power
to run by default.  (My guess.)


> >
> > The fully functional kernel will normally be loaded from
> > the internal flash disk.  It will be able to verify the
> > rest of the system.
> >
> > The kernel that boots from the USB flash drive would be
> > used if the kernel in the internal flash drive was not
> > usable.  It can reload files that are corrupted or missing.
> > It can also reformat and reload the internal flash drive
> > from scratch.
> >
> > In order to securely update the system, a new signed
> > signature file would accompany any updates. The new
> > signature file would replace the old one, and any files
> > with differing signatures would be replaced. The signature
> > files would be dated and the person doing the update would
> > have to verify that the date was reasonable to prevent
> > updates to old versions with known security problems.
> > Alternately the signature files could have serial numbers
> > and the update software would refuse to update to an older
> > serial number.
> >
>
> This must be entirely automated.  It cannot require knowledge or
> intervention of either the children or the teachers.

OK I was going overboard and trying to protect from an compromised
signature.  There are other ways of fixing the problem I was trying
to solve.

>
> In conventional packaging systems (e.g. Debian apt), what typically
> happens is that there is a meta package which has a signature; it itself
> can be updated if the signature is valid.  By its declaration of
> dependencies, everything else gets pulled in/updated.
>
> I suggest you study current practice in Linux packaging systems.

Good idea, I have not looked at the mechanics behind packages for years.
(Maximum RPM had been my referance.)  I was approaching this project as
a system integrity and repair tool more than a system managment tool,
although both are required, and have to work together.


>
>
> > Programs like Firefox, that interact with the net,
> > will require special measures. Either they will run in
> > a chroot jail,
>
> chroot jails are problematic at best, and do not provide full
> guarantees.
>
> >  or SELinux features can be used to limit
> > them to reading and writing very specific sets of files
> > and directories.  Although SELinux is more complicated,
> > it is probably the best way to go.
>
> SElinux is probably the right answer for at least "standard" network
> services.  Whether the policies will need modification for our
> environment is, I would guess, probable.

OK SELinux it is.

>                             Regards,
>                               - Jim
>
> --
> Jim Gettys
> One Laptop Per Child
>
>
>
After I get some feedback here, I think that I will move the discussion
to [OLPC-devel]  to get more general feedback.

Would this be a good time to apply for an A-test board?