#LyX 1.1 created this file. For more info see http://www.lyx.org/ \lyxformat 2.15 \textclass article \language default \inputencoding latin1 \fontscheme default \graphics default \paperfontsize default \spacing single \papersize Default \paperpackage a4 \use_geometry 0 \use_amsmath 0 \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \defskip medskip \quotes_language english \quotes_times 2 \papercolumns 1 \papersides 1 \paperpagestyle default \layout Title Package Verification with dpkg: Implementation \layout Author John Goerzen \layout Date Version 5; January 4, 2001 \layout Section Introduction \layout Standard As part of a continuing effort to improve the security of users of Debian and Debian-based systems, one step that is important to take is to allow the users to verify for themselves that .deb packages that they have are from an authentic source. This mechanism is intended to prevent various types of attacks. Some are: \layout Itemize Preventing people from setting up a fake Debian archive, containing potentially trojaned packages, and masquerading as a real Debian archive. This attack can be thwarted by checking an origin signature, checking archive signatures, or checking maintainer signatures. \layout Itemize Preventing altered .deb packages from being installed undetected. Since all signatures are applied to the contents, any signature that is checked will protect against this attack. \layout Itemize Preventing people from separating or inserting forged data or metadata into a package. Because all signatures are applied to both the control and the data chunks together, separating them will not be possible without causing a signature failure. \layout Itemize Helping to prevent old packages from being presented as new. By checking the signature date, policy files can be set to reject packages that contain old signatures. Sites might re-sign their packages periodically with an \begin_inset Quotes eld \end_inset archive \begin_inset Quotes erd \end_inset or a \begin_inset Quotes eld \end_inset timeliness \begin_inset Quotes erd \end_inset signature that could be used specifically for this purpose. \layout Itemize Allowing verification to ensure that a given package was part of a particular archive site, distribution, made by a particular developer, etc. Signatures could be applied for various stages of development -- approval by QA managers, release managers, etc. The multiple signature per .deb architecture outlined in this proposal allows this. \layout Itemize Allowing verification of an isolated .deb, even in the absence of an Internet connection or access to an archive. By including the signatures inside the .deb itself, it is not necessary to download signed index files to verify a signature. \layout Subsection Unaddressed Problems \layout Standard The approach set forth in this document leaves one hole that must be solved by other means. That problem is the task of insuring the integrity of the keys, policy files, and programs themselves used to carry out the verification. One potential solution is to modify apt-get to support https and use trusted third-party (e.g., Thawte) to shore up this problem. \layout Standard The mechanism used to ensure old packages are not presented as new might be resource-intensive on the server in some situations. One potential avenue to explore there might be to provide signed Packages files on the server. \layout Subsection Rationale \layout Standard Some thought has gone into the design of this particular solution. For benefit of future discussions, here is some information on how this mechanism was chosen and reasons for it. Here are the main alternatives that have been considered: \layout Description GPG\SpecialChar apt, genchanges, and various other utilities. The additional complexity of doing so and the possibility of separating the signature from the .deb makes this approach undesirable. \layout Description GPG\SpecialChar However, this would change the basic format of the .deb and render it unusable without a current dpkg and GPG installed on the system. Since it breaks backward compatibility in such a severe way, this approach is also undesirable. \layout Description Sig-per-chunk A sig-per-chunk system would place separate sigs in the ar file for the data and the control chunks. Unfortunately, this would allow someone to mix and match data and control data in making trojan .debs, which can also be a security threat. \layout Description Sig-per-repository A sig-per-repository system would place an md5sum of a .deb into the Packages files and sign those. However, this omits fine-grained control and prevents verification of a .deb in absence of the Packages file from the Internet. It also requires solutions to problems of determining which archive a package came from. \layout Standard The policy files (see section \begin_inset LatexCommand \ref{Policy Definitions} \end_inset ) are designed to be simple, straightforward, and easy to both write and parse. By keeping them as simple as possible, the potential for both human authoring errors and parsing errors in software can be minimized. \layout Section Modifications to .deb \layout Standard Currently, a .deb consists of an ar archive containing debian-binary, control.tar.g z, and data.tar.gz files. These files represent package meta-data and package contents, respectively. Each signature will be applied to the debian-binary, control.tar.gz, and data.tar.gz files concatenated together in that order. The files should not be decompressed before applying the signature. \layout Standard Each signature file will be stored in the ar archive and have a name of this form: \layout Standard _gpg \emph on type \layout Standard Therefore, an origin signature would be named _gpgorigin. The \begin_inset Quotes eld \end_inset type \begin_inset Quotes erd \end_inset string must not exceed 10 characters in length nor be less than 1 character. \layout Standard Therefore, an origin signature in GnuPG format would be named _sig-origin.gpg. At this time, all signatures must be in GnuPG format. \layout Section Signatures and Types \layout Standard Each .deb file that is signed must have at least an origin signature. This signature should be unique per entity. For instance, Debian, Helix, and Progeny would each provide an origin signature. The origin signature is used as a key into the policy database such that the proper policy description can be loaded to describe the file. \layout Standard Beyond the origin signature, the signature types that are present or required are defined by the site policy. Examples of other signatures might be a maintainer signature from the person that built the package, a signature from quality assurance certifying that the package has passed QA tests, a signature from a release manager certifying that a package was part of a given distribution release, and a signature from an archive maintainer certifying that the package went into an archive. \layout Section A Runthrough \layout Standard To make sure the entire process is entirely clear, here is what will occur when a package is processed: \layout Enumerate The Key ID of the origin signature will be obtained. This will be used to determine the directory in which to look for policy files and keyrings as specified in section \begin_inset LatexCommand \ref{locations} \end_inset . \layout Enumerate The checker will iterate over each policy file in that directory in an arbitrary order, doing the following: \begin_deeper \layout Enumerate Compare the Origin: line in the policy file (see section \begin_inset LatexCommand \ref{Origin line} \end_inset ) with the Key ID of the origin signature. If there is a difference, immediately die because of suspected corrupted policy files. \layout Enumerate Evaluate the selection clauses, if any, in the policy file. If there are any that do not pass, skip to the next policy file. If all of them pass, or there are no selection clauses, adopt the current policy file as authoritative for the package. \layout Enumerate If no appropriate policy files are found, reject the package as having a bad (unverifyable) signature. \end_deeper \layout Enumerate Given the appropriate policy file, the checker will iterate over every verificat ion clause in that file. If all of them pass, the package is considered to pass the test. If any of them fail, the package is considered to have failed the test and processing immediately exits. No other policy files will ever be tested after this point. If the policy file contains no verification clauses, it will be rejected as invalid. \layout Standard It is possible that other package verifiers that use the same .deb architecture but different verification procedures may be introduced in the future. This section is not intended to imply a prohibition against such. \layout Section File Locations \layout Standard The following locations are defined for files that comprise this system: \begin_inset LatexCommand \label{locations} \end_inset \layout Itemize /etc/debsigs/policy/ \emph on Origin-ID \emph default /* contains one or more policy files that are to be applied for .debs whose Origin key was signed by the Key ID as listed in the path. The policies are tried in a non-deterministic order until one matches the selection criteria. Once one matches the selection criteria, the success or failure of the entire check is entirely contingent upon the success or failure of the verification clauses. If no policy file matches the selection criteria, then the entire operation is determined to fail. \layout Itemize /usr/share/debsigs/keyrings/ \emph on Origin-ID \emph default /* contains one or more keyrings that are used by the policy files for the given origin. They may be symlinks to keyrings located elsewhere if desired. This is used as the directory for the keyrings in the RequiredSig and OptionalS ig lines unless an absolute path is specified there. \layout Standard The policy files are located in /etc because sites may opt to alter the criteria for installing files on their site. The keyrings are located in /usr/share because they should not be altered locally. Because of the multi-file and multi-directory nature, it is easy for organizati ons to provide packages providing information for verification of certain things. For instance, Debian could provide a debian-debsigs-potato package which contains a policy file and a potato release file. It could depend on debian-debsigs-main package, which contains the keyring for the origin field, a symlink to the main Debian keyring for the maintainers field, and a dependency on debian-keyring. \layout Section Related Documents \layout Bibliography \bibitem {1} de Winter, Brenno. \emph on Gnu Privacy Guard Mini Howto \emph default at http://www.dewinter.com/gnupg_howto/english/. \layout Bibliography \bibitem {2} Free Software Foundation. \emph on The GNU Privacy Handbook \emph default at http://www.gnupg.org/gph/en/manual.html. \layout Bibliography \bibitem {3} Free Software Foundation. \emph on gpg manpage \emph default available on local systems with gpg or at http://www.gnupg.org/gpgman.html. \layout Bibliography \bibitem {4} Braakman, Dorman, et al. \emph on Debian Packaging Manual \emph default at http://www.debian.org/doc/packaging-manuals/packaging.html/. \layout Bibliography \bibitem {5} Quinlan, Daniel. \emph on Filesystem Hierarchy Standard \emph default at http://www.pathname.com/fhs/. \layout LyX-Code \the_end