Package and distribution security

Package and distribution security

The aim of this chapter is to describe the security state of the art in package delivery of opensource *nix distributions. First chapter summarizes the main concepts of cryptography in order to understand the rest of the document. Next chapter lists and discusses security aspects of package distribution in the major *nix distributions. Following chapter explains the method used to mirror sites today. Last chapter discusses the advantages of using P2P networks in order to distribute packages and distributions; in particular in paragraph 5.3.2 it will be proposed a model in order to integrate P2P with PGP (Pretty Good Privacy).

Security Basics

All security mechanisms deployed today are based on either symmetric/secret key or asymmetric/public key cryptography, or sometimes a combination of the two. Here we will introduce the basic aspects of the secret key and public key techniques and compare their main characteristics.

Secret Key Techniques: Secret key techniques are based on the fact that the sender and recipient share a secret, which is used for various cryptographic operations, such as encryption and decryption of messages and the creation and verification of message authentication data. This secret key must be exchanged in a separate out of bound procedure prior to the intended communication (using a PKI for example).

Public Key Techniques: Public Key Techniques are based on the use of asymmetric key pairs. Usually each user is in possession of just one key pair. One of the pair is made publicly available, while the other is kept private. Because one is available there is no need for an out of band key exchange, however there is a need for an infrastructure to distribute the public key authentically. Because there is no need for pre-shared secrets prior to a communication, public key techniques are ideal for supporting security between previously unknown parties.

Asymmetric Key Pairs: Unlike a front door key, which allows its holder to lock or unlock the door with equal facility, the public key used in cryptography is asymmetric. This means just the public key can encrypt a message with relative ease but decrypt it, if at all, with considerable difficulty. Besides being one-way functions, cryptographic public keys are also trapdoor functions- the inverse can be computed easily if the private key is known.

PGP

PGP, or "Pretty Good Privacy", is a program that is intended to help make electronic mail more secure. It does this by using sophisticated techniques known as public key encryption. If you find yourself wondering what electronic mail and making information unreadable by spies has to do with RPM, you have a good point. However, although PGP claim to fame is the handling of e-mail in total privacy, it has some other tricks up its sleeve.

Encryption and digital signature

As we mentioned above, PGP uses public key encryption to do some of its magic. You might guess from the name that this type of encryption involves keys of some sort. But, as you might imagine, these are not keys that you can copy down at the local hardware store. They are large numbers. PGP uses two different types of keys: public and private. The public key, as its name suggests, can be shared with anyone. The private key, as its name suggests, should be kept secret. PGP creates keys in pairs - one private and one public. A key pair must remain a pair; if one is lost, the other by itself is useless. Why? Because the two keys have an interesting property that can be exploited in two ways:

• A message encrypted by a given public key can only be decrypted with the corresponding private key.
• A message encrypted by a given private key can only be decrypted with the corresponding public key. (Digital signature)

The state of the art in package security

In the following sections it will be discussed the security criteria used in the major distributions today.

RPM

The RPM Package Manager [40] (RPM) is a powerful command line driven package management system capable of installing, uninstalling, verifying, querying, and updating computer software packages. RPM are used in distributions like Red Hat, Mandriva and Suse. RPM security consists in a PGP/GPG signature inserted inside the rc file of the RPM: before installing the package the RPM manager tries to verify the signature: if this operation fails (e.g. there is no public key to verify the file, or the package is corrupted) the installation process aborts. However, signature process is not mandatory so there are a lot of RPM packages that are not signed. These are some examples of command useful to manage the digital signature of RPM files:

rpm --showrc

rpm --sign

rpm --checksign

rpm --resign

rpm --addsign

DEB Package

Deb files denote Debian packages [39] and the main tool to manage them is apt. The current scheme for package signature checking using apt is:

1. The Release file includes the md5sum of Packages.gz (which contains the md5sums of packages) and will be signed. The signature is one of a trusted source.
2. This signed Release file is downloaded by 'apt-get update' and stored along with Packages.gz.
3. When a package is going to be installed, it is first downloaded, and then the md5sum is generated.
4. The signed Release file is checked (signature ok) and it extracts from it the md5sum for the Packages.gz file, the Packages.gz checksum is generated and (if ok) the md5sum of the downloaded package is extracted from it.
5. If the md5sum from the downloaded package is the same as the one in the Packages.gz file the package will be installed otherwise the administrator will be alerted and the package will be left in cache (so the administrator can decide whether to install it or not). If the package is not in the Packages.gz and the administrator has configured the system to only install checked packages it will not be installed either.

Currently, this scheme is fully implemented in apt 0.6, which is available in the experimental distribution. These changes are based on the patch for apt, which provides this implementation.

Slackware Packages

The Slackware package management system is very simple: each package consists of a tar gzipped file containing all the file to be installed plus some meta file containing package information and installation scripts. Package security is very similar to Debian system and consists in maintaining a file called CHECKSUMS.md5 containing all the md5 hashes of every file in the distribution; in another file called CHECKSUMS.md5.asc there is the PGP digital signature of the first file. Currently there is no automatic verification process so the users have to manually check the signature using the gpg software (gpg -verify).

FreeBSD Packages

FreeBSD distributes (like all the major Linux distributions) both precompiled package and source package: the former type is called "package" the latter "port" [38]

1. The package contains pre-compiled copies of all the commands for the application, as well as any configuration files or documentation.
2. A FreeBSD port for an application is a collection of files designed to automate the process of compiling an application from source code.

~~ MD5 (MailScanner-install-4.39.6-1.tar.gz) = efe4a1eec0b072febbb3d6037a65470d

SIZE (MailScanner-install-4.39.6-1.tar.gz) = 4854418 ~~

The ports are also cheksummed and the hashes information are contained in a file called +CONTENTS:

@comment MD5:57a0384ff515dc68439840a4ea9892f7

However FreeBSD provide a tool called pkg_sign that is able to sign packages with GPG keys or X509 certificates but this method is not official.

portage (gentoo)

Portage is software packages for Gentoo Linux; they tried to emulate FreeBSD Ports system and they follow the same philosophy. Everything can be downloaded as source code and compiled right for the architecture of each system [37]. Now there is no security mechanism in portage distribution but Gentoo developers have decided to move to a new and more secure format.

As part of an overall effort to improve the security of Gentoo Linux, the Portage development team is starting to implement some new features in Portage which will allow for increased security in package management and distribution system. One of the first new features that users will notice is a digest of every file involved in the merge process, including ebuilds, patches and source tar balls. In addition to offering increased security, these digests will help isolate and track down corrupt ebuilds or other files on our rsync and source mirrors.

The next step in the process will be signing these digest files with a GPG key to ensure non-repudiation. While there is still some discussion amongst the development team on the best way to achieve this, the current leading solution involves each developer signing ebuilds individually, and then one master Gentoo "uberkey" signing all of the developer keys to establish a Gentoo "web of trust". Developer keys will be made available through public key servers, as well as on www.gentoo.org

The goal of what has come to be known as "Secure Portage" is to provide a robust package management system that offers end-to-end security in the emerge process. As yet, there is no confirmed timeline on when the entire system will become available, but the digesting portion is in testing now and the rest will soon follow.

Mirroring

Mirroring with rsync

The actual method used for syncing master distribution servers with mirrors around the world is done with various tools. The mechanism for a mirror is: connect to the master server and download new packages/files. The most used tool for mirroring is rsync.

Rsync [41] is a replacement for scp/rcp that has many more features. Rsync uses the "rsync algorithm" which provides a very fast method for bringing remote files into sync. It does this by sending just the differences in the files across the link, without requiring that both sets of files are present at one of the ends of the link beforehand. At first glance this may seem impossible because the calculation of diffs between two files normally requires local access to both files.

Rsync normally uses ssh or rsh for communication [42]; another solution is using it in conjunction with stunnel [43]. It does not need to be setuid and requires no special privileges for installation. You must, however, have a working ssh or rsh system. Using ssh is recommended for its security features.

P2P Security aspects

Security in P2P nets is very important because the number of download sources can be very big and each node can hide a potential "bad guy". So it should be found system able to guarantee the authentication and eventually also the privacy for each connection of every peer.

Nowadays there are fundamentally two standard protocols used to reach application or network security: SSL and IPSec. The next section describes some features and highlights the reasons why they cannot be used in P2P networks easily.

Security Protocols

Mechanisms for establishing strong, cryptographically verifiable identities are very important. These are industry standard authorization protocols that allow peers to ensure that they are speaking with the intended remote system.

Secure Sockets Layer (SSL) protocol:

For protection of information transmitted over a P2P network, some P2P's employ the industry-standard Secure Sockets Layer (SSL) protocol. This guarantees that files and events sent will arrive unmodified, and unseen, by anyone other than the intended recipient. Moreover, because both peers use SSL both sides automatically prove who they are to each other before any information is transferred over the network. The protocol provides mechanisms to ensure tamperproof, confidential communications with the right counterpart, using the same, well-proven techniques used by all major website operators to protect consumer privacy and financial information transmitted on the Internet.

IPSec technologies:

Most VPNs (virtual private networks) use IPSec technologies, the evolving framework of protocols that has become the standard for most vendors. IPSec is useful because it is compatible with most different VPN hardware and software, and is the most popular for networks with remote access clients. IPSec requires very little knowledge for clients, because the authentication is not user-based, which means a token (such as Secure ID or Crypto Card) is not used. Instead, the security comes from the workstation's IP address or its certificate (e.g. X.509), establishing the user's identity and ensuring the integrity of the network. An IPSec tunnel basically acts as the network layer protecting all the data packets that pass through, regardless of the application.

Both methods described above have problems when the number of peer increases. In fact:

1. SSL needs of a PKI based on X509 certificates (PKIX): this kind of PKI cannot adapt to a P2P network because the PKIX has a hierarchical and centralized model, while p2p has a distributed model.
2. IPSec needs a PKIX or the distribution out of band of pre-shared-keys

P2P security models

The constant running theme in the security of P2P is that of trust. Trust in the other users who we interact with, and trust within the software vendors who supply us with the necessary applications. If we could have more faith in this trust, or feel a greater sense of security, maybe the development of P2P would grow even faster than it is already doing.

Many proposals are already being studied. People are acknowledging that security is an area that P2P must address, if it is to be accepted by consumers.

Users Gaining Their Own Trust

One very interesting idea recently proposed [48], is that of users gaining trust within the P2P community. All users would be assigned a unique digital signature, like IP, but per user and not per machine. Associated with this digital signature would be a level of trust. Trust levels would vary from say zero, to twenty. Depending on users behaviour in the past, their trust level would either be promoted on the grounds of valid use of the network, or demoted with acts of malice and misuse.

The proposed plan states that all users trust level would begin at a rather low level. This is merely to combat unwanted users creating new accounts, and abusing the new high trust level immediately. Users would have to be active on the network for some time (say one/two months), before their trust level would be pushed up a level. Users could also keep a local record of other known users, to which they may want to share a local trust level, and bypass the global trust policy.

This proposal has many hurdles to jump of course. It is merely an idea to be developed. The problem that it overcomes is that of the centralized managing authority. Instead, the users of the network are the authority. If the general public continuously tries to demote an user, he will eventually lose all his privileges, and become silenced from other users. This idea also rewards genuine users, for their efforts in keeping the network policed, and for their good behaviour on the network.

The idea is possibly a bit too naive, as we all know that most humans (especially adolescent ones), will do the exact opposite of what they are meant to do, if given no choice. In other words, people do not like to be told what to do.

The integration of P2P and PGP

The goal of this section is to describe a hypothetical system that integrates the use of PGP and P2P networks; the integration is natural because both use distributed model.

To increase P2P security each node should have a PGP key in order to authenticate itself and the other nodes through challenge-response protocols (similar to SSL). If a node wants to download a file in a secure way should bind connections only to trusted nodes (we can call them "friends"); like PGP we can trust also in the "friends" of the "friends" till to a configurable depth. So the typical PGP web of trusts will coincides with a sort of a "web of downloads".

This system achieves the following goals:

• A user can download in a secure way file (like distributions) form trusted people more efficiently than download using traditional transfer protocol (like https). The figure below shows this scenario (blue nodes mean "trusted nodes"; red nodes mean "untrusted nodes"; black rows mean "neighbour node"; blue arrows mean "download sources"). The depth of the web of trust is 2

• A master site can define a set of official mirror sites and choose to distribute the software using P2P/PGP; in this scenario it will be authenticated both the master site both the slave sites. The figure below shows this scenario: A is the master site; red nodes cannot syncs with A because A doesn't recognize them like trusted nodes ("friends", "official mirror sites"):