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

[Jim Gettys]

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?

> 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. There is still some question on whether we should go the
conventional packaging route, however.

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.  

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

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

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

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

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.

> 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.
                             Regards,
                               - Jim

-- 
Jim Gettys
One Laptop Per Child