Secure APT in Debian 4.0

Secure APT – Debian increases Security

For several years the Debian project provides digitally signed archives that aims at protecting their users. These intend to prevent users from installing malicious packages injected by an attacker. With the recent release of Debian GNU/Linux 4.0 alias etch the default installation of Debian includes the needed framework to check these signatures automatically.

1. Injecting malicious packages 2. Digital signatures 3. Digitally signed archives 4. Signed packages? 5. Key management 6. Graphical Key Manager 7. Tuning

The Debian system is distributed using various techniques. One way to install Debian GNU/Linux is to purchase a CD or DVD from a distributor and hope that the selling company has done everything correct and can guarantee the authenticity of the distribution. Once installed, updates such as security updates and critical updates in stable updates are retrieved from the Internet.

Thus, the most commonly used way to access packages from the Debian archive is via the Internet. To make this possible for its users the Debian project has configured several machines that provide HTTP, FTP and rsync access. Additionally the community has set up a large number of mirror servers to serve the growing need for fast access.

With the release of Debian GNU/Linux 4.0 the package manager APT will automatically check digital signatures provided by the Debian project. This ensures that only authenticated packages are installed and that only integer archives are used. It prevents malicious packages from accidental installation.

Injecting malicious packages

After the base installation which is often done using a CD or DVD based method users often fetch more packages and updates from one of the many archive mirrors on the Internet. This, however, bears some risk. An attacker who has managed to get control over the mirror or a proxy between the user and the mirror server could simply alter the mirror's content. Eventually the user would install a specially crafted package.

Before the release of etch the user normally wouldn't notice if a package in the archive has been exchanged with a version that contains a backdoor or an older security problem that was fixed in a more recent version. During the update »apt-get« would simply fetch and install the malicious package if it has been mentioned properly in the »Packages« file which denotes the index listing of all available Debian packages in a given suite for a given architecture.

Digital signatures

The Debian archive contains digital signatures for several years already. However, there has been no standard framework to check them properly. With the release of etch this has finally been changed. The default configuration of the APT package manager is to read and check these signatures. If they don't match the archive it will complain and not download the packages unless manually overruled. All users who haven't manually turned this feature off will thus benefit from authenticated archives.

To achieve this both packages »gnupg« and »debian-archive-keyring« need to be installed on the system. They are already present when a new installation or an upgrade from an older release is performed. If one of these packages is missing, »apt-get« will complain that some packages cannot be authenticated when they are to be installed. (See below on how to turn the checks off.)

The Debian project utilises commonly used programs to create and check digital signatures instead of reinventing the wheel again. No special tool has been developed by the project, but instead an established cryptographic utility is used. The GNU Privacy Guard (GnuPG) is able to maintain digital keys and signatures. It has been integrated in the Debian archive infrastructure several years ago.

Digitally signed archives

First of all, the Debian project does not provide signatures for individual packages. This would cause too much overhead for only little security. However, for several years there have been discussions on Debian development mailing lists about how digital signatures are to be handled and should be maintained for the Debian archive. There have always been proponents of signatures per package, but this would have several drawbacks.

Instead, for a given distribution (stable, testing, sarge or etch to name only a few) there is only one digital signature instead of about 12,000 * 12. This way »apt-get« does only have to verify a single signature during an upgrade. This is a notable time benefit for users who intend to upgrade a lot of packages at once.

In the official Debian archive source and binary packages are organised in components (»main«, »contrib«, »non-free«), suites (»stable«, »testing« etc.) and architectures (»i386«, »arm«, »m68k« etc.). For each combination of these three a separate index file is provided, so that »apt-get« does not have to fetch a list of all available packages but only of relevant ones.

These index files are named »Packages« and are also stored in compressed form to save bandwidth when the requesting program understand how to uncompress them. They contain all information a package manager needs to know about binary packages. This includes general meta information such as a description and dependency information as well as the path to the respective file in the archive and an MD5 hash of the binary package itself.

Thus, if the Packages file was digitally signed, all referenced binary packages inside would inherit the signature since the MD5 hash is sufficiently unique. This technique is used by the Debian project indeed. However, all »Packages« files for a given distribution are referenced with their respective MD5 hash in just another file in the main distribution directory called »Release« for which finally a digital signature is provided.

Hence, Debian provides a digital signature per distribution that covers all components and therefore all source and binary package files. This is much more powerful and less time consuming for the end user who would like to ensure that the files they download are really coming from the Debian project.

Every time »apt-get« fetches the index files, the digital signatures of all corresponding files are verified. Whenever packages are to be fetched from the network, the package manager checks the integrity of the relevant index file and its signature status. When there is a problem, it will report this to the administrator.

Signed packages?

As mentioned before, there have been discussions about signed packages instead of signed index files. Signed packages help prevent the injection of arbitrary packages. However, they are no measurement against some sort of attacks. An evil person who injects an older version of a Debian package into a Debian mirror would still be successful, since the package itself would still contain a valid signature. Such a package could contain a security vulnerability that had been fixed already in a more recent version.

When the entire distribution is signed and not only individual packages, such a package couldn't be successfully injected. Its MD5 hash wouldn't match the one stored in the respective »Packages« file, unless the entire mirror would be suspended and the entire content be dated back into the past.

From a performance point of view the way Debian provides digital signatures for its archive is very friendly to the end user and a superior solution. Only a single signature needs to be checked for a number of »Packages« files and thus an even larger number of binary packages.

With individual signatures per package file the signature would have to be checked for each and every binary and source package. This would not only be quite time consuming but at the same time require a really large keyring to maintain. While the time factor can be ignored on today's dual core 2.4GHz processors, it is still an issue for older and slower hardware.

It is quite the contrary with the Debian way, since only the MD5 hash needs to be calculated for each package and each index file. This consumes extremely little time and CPU compared with signature checking.

Key management

The keys used by the Debian project are usually only used for one distribution or their updates. Those used for the recently released distribution codenamed 'etch' will not used for the next release codenamed 'lenny'. Additionally, external archives not maintained by the Debian project will have to use different keys. Thus, new utilities are required for key management.

Digital keys for the APT package manager are stored in the file »trustdb.gpg« in »/etc/apt« and are maintained with the »apt-key« program which is part of recent APT versions. In order to access the keyring the program needs to be run as »root«. It understands four arguments: »list«, »add«, »del« and »update«.

When only official Debian sources are used no additional action is required by the administrator of the system. Debian packages will automatically update the internal keyring with new versions of the digital key and remove old ones. However, when third party sources are added to the package repositories in »/etc/apt/sources.list« other keys are probably required for authentication.

For such cases »apt-key add FILENAME« is used to add another key to the keyring. The file »FILENAME« contains the digital key which is required to authenticate the repository in question. To see which keys are included in the APT keyring the list of available keys is viewed with the »apt-key list« command.

The »apt-key update« command is used to update the keyring against the archive keyring provided by the the Debian project in the package »debian-archive-keyring«. It is merely used internally by the package. This command does not only install new keys found in this package but will also remove keys that are no longer used.

Graphical Key Manager

The 21st century is the known for graphical frontends. A lot of Free Software operates with a graphical frontend that helps uses to control the computer and perform their daily work. Nowadays, most spreadsheet applications and text processors come with a graphical interface. A modern desktop system is operated via a graphical desktop environment, often GNOME or KDE.

Thus, many administrative utilities are available with a graphical frontend as well. The same applies to the package manager. While »aptitude« is used on the text console Synaptic is the graphical frontend to »apt-get«. The graphical counterpart to »apt-key« is »gui-apt-key« which provides the same functionality and adds an easy method to download and add new keys.

Tuning

When no matching digital key is present to verify the integrity of an archive »apt-get« will complain. The administrator has the choice to go on and not install the named packages or to overrule the verification and install them anyway. The administrator controls this behaviour through the configuration file »apt.conf«, similar to other features of the APT package manager.

Adding the line

   APT::Get::AllowUnauthenticated "true";

to »/etc/apt.conf« will remove this question. The names of configuration settings for APT are organised in a hierarchy. Therefore the above line can be expressed in the hierarchical representation

   APT {
     Get {
       AllowUnauthenticated "true";
     };
   };

as well. This format is mostly useful when several options are present that share parts of the naming hierarchy. Both settings will force APT to accept packages whose integrity couldn't be verified by a valid signature. It is not recommended to accept unauthenticated packages, though.

This article has been proposed to Linux Journal without raising interest and is thus presented to the public anyway.