code signing/secure boot sequence (Re: [OLPC-devel] Re: wireless/libertas: miscellaneous fixes)

[Christopher Blizzard]

Adam Back wrote:
> I'd say (wrt to wanting a copy of the same software set as your
> trusted friend has), what you want is a copy of what your friend
> thinks he has.  (Not what he actually has as that could include
> viruses etc).  ie you want a way to receive packages store-and-forward
> via relatively untrusted machines, such that they cant be modified
> without changing their authorship.
> 
> So I think one should be able to do that no?  (Get a copy of what he
> thinks he has) if there is some packager or author authentication.  So
> if you get firefox-1.5.i386.rpm it will be unmodified.
> 
> So in practice the user would have no reason to tamper with his .rpm
> cache directory (no reason rebuild rpms with software patches eg), so
> it should not fail.
> 
> Now obviously a user could cause it to fail intentionally, but they
> can do that anyway, even without code signing.
> 
> 
> About the definition of trust -- its true SSL particularly is crappy
> as it means you end up with someone -- like the CAs -- being trusted
> by everyone.  But with RPM it is actually signed with PGP, so there is
> a web of trust.  Perhaps a distributor or package builder can at least
> sign the binaries they produce?  (Its sort of what happens, if I
> subscribe to yum repo of livna or other add ons, its up to me to check
> their keys or live with the warnings about unverified signatures;
> similarly to tolerate installing unsigned rpms if I choose).
> 

I've been wanting to attack the 3rd party software problem for a while. 
  I came up with a short list of "rules" that we could use to enable a 
lot of what you list above:

1. The software format that you download is the same that you use to run 
the program.

Instead of downloading a package and dropping it into your filesystem 
with files all over the place, everything runs from a single directory 
location.  You should be able to pick up an application and move it from 
one place on the filestem and move it somewhere else and have it just work.

For the record, this is a lot easier to do with end user facing apps 
because we can assume a smart launcher.  We don't have to assume that 
everything has to be in the shell path and we can assume that an 
environment to find libraries, config files, etc has been set up for the 
program.

2. If you have an installed application you can just tar it up and give 
it to someone else.

That is, if you can run the program you can also give it to someone 
else.  In the linux world today a .deb file or an .rpm file have no real 
relation of what it ends up looking like on disk.  They are free to 
change files, drop files all over the place during post install, etc. 
So you can't take the database and the files on the filesystem and just 
give them to someone else.

[ I guess I should say here that what I'm describing is possible, of 
course, but it's not guaranteed by the packaging formats nor is it even 
in the minds of people doing the packaging. ]

Now, to enable a sense of security, and if we have a single way of 
installing and sharing software we can make a few assumptions:

1. Applications are installed read only
2. Configuration files are not part of the installed application image
3. User data is completely separate from configuration and applications

If you can make those assumptions, it makes a lot of things really easy. 
  Think about backups.  You only have to back up one copy of an 
application across many machines, you know exactly what a user really 
owns, and imaging a machine and re-installing become trivial.

--Chris