A simple signed bundle/directory trust scheme for the XS

[Martin Langhoff]

The XS now has a few new packages that allow it to auto-install
certain types of content (XO installation builds, for starters) from
USB keys. This means that I have to address validating that such
content comes from a trusted source.

So I am setting up a simple and straightforward authentication scheme
for the XS. It does not attempt to solve very possible problem --
physical access to the box and various other issues conspire against
us. It humbly attempts to establish a simple yet reasonable chain of
trust.

Comments welcome. Please do keep in mind that I am trying to keep it
simple and implementable in a short timeframe.

There following are the main moving parts in this scheme.

- Initial installation / boot is trusted. During installation and/or
initial boot the XS will read a set of trusted public GPG keys from a
USB drive, and copy them somewhere in /etc - more that one set of
trusted keys is ok. If this happens, a file will exist in /etc
indicating (to scripts and sysadmins) that signature checks are
enforced. We may signal this in visible UIs too.

- "Signed content" -- we will consider content as signed correctly if
it has at its top directory a file called manifest.sha1 that validates
the rest of the files in the directory and a manifest.sha1.sig file
containing a GPG signature of manifest.sha1 , signed with one of the
trusted keys. To avoid race conditions affecting files in a
world-readable directory, the checks should be performed in a safe
tmpdir.

- "Signed content" maybe a dir on a usb key, or a directory in a
zipfile or a tarball. As long as manifest.sha1 provides a valid
manifest for all the files in the corresponding directory and
subdirectories. Anything that unpacks to a directory is ok. We will
use this scheme for a wide range of things - the files may be
retrieved by the XS via the network, or uploaded by users via web
interfaces.

- Extraneous files - not listed in the manifest - cause an error.

- We trust signed content - this includes scripts that will run as
root, and can add new pub keys to the trusted set.

- If we are not in 'enforcing mode' (XSs in pilots, for example) then
we don't check for signatures.

- Extraneous files and mismatched SHA1s *always* cause an error.

- A utility called xs-check-signature Does the Right Thing (including
logging) for scripts when passed the path to the manifest.sha1 file.

that's all. More words than implementation code probably - :-)

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff