NSBD and Software Distribution

Dave and Katherine are members of the technical staff at Bell Labs. They can be contacted at [email protected] and [email protected], respectively.

Not-So-Bad Distribution (NSBD) is a web-based system for automatically distributing free software over the Internet, where users cannot trust the network and cannot entirely trust the maintainers of software. To authenticate packages, NSBD uses Network Associates' Pretty Good Privacy (PGP) digital signatures, so users can be assured that packages have not been tampered with. NSBD also limits the maintainer to updating only selected files and directories on the user's computer. NSBD's focus is on security, leaving as much control as is practical in users' hands. In short, NSBD lets users control the update of software in their machines, yet automatically keep current with the latest release of software packages.

To accomplish automated updates, NSBD supplies a means of checking for updates to packages and automatically downloading and installing the updates. This "automated-pull" style of distribution has the same effect as the push style of distribution, but gives more control to users. A direct push style is also supported (though it is not used as frequently, it is especially appropriate for situations where there are multiple contributors to a shared server, as with a shared web-page server).

NSBD is freely available at http:// www.bell-labs.com/nsbd/ and from DDJ (see "Resource Center," page 3), and is released under the terms of the GNU General Public License. Binaries and source (it is written in Tcl/Tk and C) are available for a variety of UNIX platforms, and we have plans to port it to Windows.

Establishing a Web of Trust

PGP is a public-key encryption package that allows secure communication without requiring the prior exchange of keys over secure channels. NSBD uses PGP to manage digital signatures -- encrypted checksums over entire files that only the owner of a private key can generate, but everyone with access to the corresponding public key can verify.

How do you know that a public key actually belongs to the person you think it belongs to? You verify this by having people called "certifiers" apply their digital signatures to the public key. Having one central, trusted certifier is difficult given the connectivity of the Internet. But you don't need one central certifier. Like the Internet itself, PGP is designed for open collaboration and allows anyone to certify public keys. You can then ensure that the key belongs to the originator through a web of trust you establish.

For example, if Philip Zimmermann (the author of PGP) certifies the public key of someone, you can probably trust it. Or, if a person you know who is knowledgeable about PGP certifies the public key of someone, you can probably trust it.

There are PGP key servers available on the Internet that contain the public keys of large numbers of people. Many of the keys are certified by many other people (see "PGP Web of Trust Statistics" at http://bcn.boulder.co.us/~neal/pgpstat/). You decide which of the certifiers you trust to introduce public keys to you and establish your own web of trust.

Why Use NSBD?

NSBD protects against an untrustworthy distribution network by using PGP digital signatures to guarantee that hackers haven't modified the software package. For NSBD to verify the authenticity of the package, providers must apply digital signatures to the package and make their public keys available. Assuming that the public keys are properly certified through your web of trust (and that providers have taken proper care to protect their private keys from being stolen), you can be assured that only updates from the authorized providers will be automatically installed because only the authorized provider controls the PGP private key.

It is important to verify that public keys are properly certified, and not all distribution systems do that. For example, the RedHat Linux "rpm" system provides support for PGP digital signatures, but it does not require that the provider is included in your web of trust. This offers only a false sense of security, since it is trivial for anyone to make up a PGP key to be used for signing viruses.

NSBD also requires that digital signatures be newer than the existing signature on an installed package, which avoids a replay attack where a spoofer forces an update back to an authentic old version.

That takes care of the untrustworthy network, but how do you know the providers themselves are trustworthy? Since the software is free and without warranty, you cannot go back to the provider to protest problems the software causes in your system. Java applets use an approach that verifies all the code in an applet, but this greatly limits what the applets can do. There are many free software packages available that are not implemented as Java applets. How can you safely use those packages? You can start by reading the mailing lists of a particular package to ensure that the provider has a decent reputation. Another useful thing to look for is whether the source code is available and people are able to verify it.

This may be enough when you personally download the software once. However, with automated updates, it becomes easy for malicious providers to affect a lot of people quickly, then cover their tracks. So, you want to automate the verification process as well. When you set up automated updates with NSBD, you can protect your computer from certain types of damage. With NSBD:

• Providers update only certain directories and files that you allow; they cannot write all over your system.
• You explicitly specify what NSBD will execute on your system after an update. This is unlike what often occurs in purchased software (and the Debian Linux "dpkg" and RedHat Linux "rpm" systems) where packages include scripts that run as root on your system.
• At the time of distribution, you only get the files. Once you execute a program file, it can do anything that your user ID allows. However, you don't have to execute it immediately. You can wait and see if others have problems.
• You can insulate packages from different providers installed on a single machine by using one user ID to install the packages and another ID to execute the programs in the packages. Since programs are never executed by the ID that installed them, they cannot modify the files of other packages. You can garner even more protection by installing packages on a server and executing the programs only on other machines.

The NSBD security model is also ideal for secure redistribution. For example, Bell Labs has a redistribution system called "Exptools" in which individuals around the company use NSBD to install packages onto an especially secure dedicated master server. From there, the packages are distributed to a large number of geographically placed intermediate servers that are not dedicated and not specially secured. However, the NSBD checksum files, on which the original maintainers have manually applied digital signatures, are redistributed along with the packages and are used to verify the authenticity of all files on each end server. If someone breaks into any intermediate server and tampers with distributed files, the corrupted files will not go any further.

How to Use NSBD

The single NSBD program handles operations performed by both providers/maintainers of packages and users of packages. This is the basic operation:

1. Maintainers make their package files available at an http or ftp URL.

2. Maintainers create an NSBD Package Description file, called ".npd," to describe their package, specify where the files are on their systems, and suggest values for installation parameters. They may include multiple binary-executable types in a single package, and users can select the types they want.

3. Maintainers run NSBD interactively with the .npd file to indicate that they have approved the files. This step creates the .nsb file, which contains the URL for the files in the package and secure checksums for each file. This step also uses PGP to apply a digital signature to the .nsb file.

4. Maintainers make the .nsb file available at a URL with a MIME Content-type of "application/x-nsbd" by either changing the default in their http server for the .nsb extension or by using a CGI script.

5. Maintainers update their packages by changing their files, rerunning NSBD to create a new .nsb file, and making their files available again at the same URL.

6. A user registers for a software package by clicking on a hyperlink to the URL of the .nsb file in a web browser. NSBD is invoked with the -register option, which pops up a window from which the package can be registered and installed.

7. A user runs nsbd -poll periodically to check for changes to the .nsb file. If the signature has changed and is valid, the files whose secure checksums have changed will be loaded. If all the loaded files match the checksums, they will be installed where the user wants them. Files that have been removed from the package will be removed from the user's copy. The user is assured that if multiple files have changed they will always be installed together.

8. Users may permit maintainers of packages to directly push package updates. To use this mode of operation, users install supplied CGI scripts and maintainers invoke them to directly send in updates, rather than making the package available at a URL. Users retain control by having all the same checks occur, with maintainers controlling only when the updates are done, not how.

NSBD Examples

The general format of each line in an NSBD file is keyword plus colon (:) followed by whitespace followed by value. Values that are lists may either be comma-separated on the same line or indented on following lines. Subkeywords may be indented further below list items.

Listing One s a sample package-description file for the NSBD binary package "nsbd.npd." To update the file to include complete comments for each available keyword, enter nsbd -updateComments nsbd.npd. To create the .nsb file from the package description, enter nsbd nsbd.npd. To register for a package, users click on a hyperlink in their web browsers or run the command nsbd -register http://www.bell-labs.com/ project/nsbd/nsbd.nsb to pop up a registration window. To manually register for the NSBD Solaris binary package rather than using a pop-up window, add Example 1 to ~/.nsbd/registry.nrd. To poll for and install updates for all packages, enter nsbd -poll all.

Conclusion

The fundamental security model of NSBD is that users retain control and give away only what is necessary to get the update done. Only authenticated updates from authorized providers are accepted. Files are limited to particular locations on the user's disk. Only user-specified commands are run after an update. Providers may suggest values for all of the installation parameters, but it is up to users to accept them. Additional reference material on the subject can be found at the Software Development Clearinghouse (http://www.cs.colorado.edu/ users/rickhall/deployment/), and in Eric S. Raymond's paper, "The Cathedral and the Bazaar," at http://earthspace.net/~esr/ writings/cathedral-paper.html.

Acknowledgments

Thanks to Philip R. Zimmermann and Garrison Keillor for inspiration for the Not-So-Bad name. Thanks to Neal McBurnett, George Otto, and John Ellson for technical discussions and many suggestions for improvements.

DDJ

Listing One

# every .npd file has to begin with the following linensbPackageDescription: 1
# PGP user ids of authorized package maintainers
maintainers:
  Dave Dykstra <[email protected]>
    # where to get PGP public key if user doesn't have it
    pgpKeyUrl: http://www.bell-labs.com/user/dwd/dwdpgpkey.txt
# binary types supported in this package
executableTypes: sparc-sun-solaris,mips-sgi-irix
# URL of the '.nsb' file; %P is package name
nsbUrl: http://www.bell-labs.com/project/nsbd/%P.nsb
# URL where all 'paths' in package can be found
topUrl: http://www.bell-labs.com/project/nsbd/binaries
# regular expression substitutions when installing
regSubs:
  # delete all .%E suffixes when installing
  .%E$
# file paths to include in package
paths:
  # %E expands to every executableType
  bin/nsbd.%E
  # recursively picks up all files in directories
  lib/nsbd/
  man/man1/nsbd.1

Back to Article