Software

RPM

RPM is a software management tool originally created by Red Hat, and later GNU'ed and given to the public (http://www.rpm.org/). It forms the core of administration on most systems, since one of the major tasks for any administrator is installing and keeping software up to date. Various estimates place most of the blame for security break-ins on bad passwords, and old software with known vulnerabilities. This isn't exactly surprising one would think, but while the average server contains 200-400 software packages on average, one begins to see why keeping software up to date can be a major task.

The man page for RPM is pretty bad, there is no nice way of putting it. The book "Maximum RPM" (ISBN: 0-672-31105-4) on the other hand is really wonderful (freely available at http://www.rpm.org/ in post script format). I would suggest this book for any Red Hat administrator, and can say safely that it is required reading if you plan to build RPM packages. The basics of RPM are pretty self explanatory, packages come in an rpm format, with a simple filename convention:

package_name-package_version-rpm_build_version-architecture.rpm

nfs-server-2.2beta29-5.i386.rpm

would be “nfs-server”, version “2.2beta29” of “nfs-server”, the fifth build of that rpm (i.e. it has been packaged and built 5 times, minor modifications, changes in file locations, etc.), for the Intel architecture, and it’s an rpm file.

Command Function
-q Queries Packages / Database for info
-i Install software
-U Upgrades or Installs the software
-e Extracts the software from the system (removes)
-v be more Verbose
-h Hash marks, a.k.a. done-o-dial

Command Example	Function
rpm -ivh package.rpm	Install 'package.rpm', be verbose, show hash marks
rpm -Uvh package.rpm	Upgrade 'package.rpm', be verbose, show hash marks
rpm -qf /some/file	Check which package owns a file
rpm -qpi package.rpm	Queries 'package.rpm', lists info
rpm -qpl package.rpm	Queries 'package.rpm', lists all files
rpm -qa	Queries RPM database lists all packages installed
rpm -e package-name	Removes 'package-name' from the system (as listed by rpm -qa)

Red Hat Linux 5.1 shipped with 528 packages, and Red Hat Linux 5.2 shipped with 573, which when you think about it is a heck of a lot of software (SuSE 6.0 ships on 5 CD's, I haven’t bothered to count how many packages). Typically you will end up with 2-300 packages installed (more apps on workstations, servers tend to be leaner, but this is not always the case). So which of these should you install and which should you avoid if possible (like the r services packages). One thing I will say, the RPM's that ship with Red Hat distributions are usually pretty good, and typically last 6-12 months before they are found to be broken.

There is a list of URL's and mailing lists where distribution specific errata and updates are available later on in this document.

dpkg

The Debian package system is a similar package to RPM, however lacks some of the functionality, although overall it does an excellent job of managing software packages on a system. Combined with the dselect utility (being phased out) you can connect to remote sites, scroll through the available packages, install them, run any configuration scripts needed (like say for gpm), all from the comfort of your console. The man page for dpkg "man dpkg" is quite extensive.

The general format of a Debian package file (.deb) is:

packagename_packageversion-debversion.deb

ncftp2_2.4.3-2.deb

Unlike rpm files .deb files are not labeled for architecture as well (not a big deal but something to be aware of).

Command Function:
-I Queries Package
-i Install software
-l List installed software (equiv. to rpm -qa)
-r Removes the software from the system

Command Example	Function
dpkg -i package.deb	Install package.deb
dpkg -I package.deb	Lists info about package.deb (rpm -qpi)
dpkg -c package.deb	Lists all files in package.deb (rpm -qpl)
dpkg -l	Shows all installed packages
dpkg -r package-name	Removes 'package-name' from the system (as listed by dpkg -l)

Debian has 1500+ packages available with the system. You will learn to love dpkg (functionally it has everything necessary, I just miss a few of the bells and whistles that rpm has, on the other hand dselect has some features I wish rpm had).

There is a list of URL's and mailing lists where distribution specific errata is later on in this document.

tarballs / tgz

Most modern Linux distributions use a package management system to install, keep track of and remove software on the system. There are however many exceptions, Slackware does not use a true package management system per se, but instead has precompiled tarballs (a compressed tar file containing files) that you simply unpack from the root directory to install, some of which have install script to handle any post install tasks such as adding a user. These packages can also be removed, but functions such as querying, comparing installed files against packages files (trying to find tampering, etc.) is pretty much not there. Or perhaps you want to try the latest copy of X, and no-one has yet gotten around to making a nice .rpm or .deb file, so you must grab the source code (also usually in a compressed tarball), unpack it and install it. This present no more real danger then a package as most tarballs have MD5 and/or PGP signatures associated with them you can download and check. The real security concern with these is the difficulty in sometimes tracking down whether or not you have a certain piece of software installed, determining the version, and then removing or upgrading it. I would advise against using tarballs if at all possible, if you must use them it is a good idea to make a list of files on the system before you install it, and one afterwards, and then compare them using 'diff' to find out what file it placed where. Simply run 'find /* > /filelist.txt' before and 'find /* > /filelist2.txt' after you install the tarball, and use 'diff -q /filelist.txt /filelist2.txt > /difflist.txt' to get a list of what changed. Alternatively a 'tar -tf blah.tar' will list the contents of the file, but like most tarballs you'll be running an executable install script/compiling and installing the software, so a simple file listing will not give you an accurate picture of what was installed or modified. Another method for keeping track of what you have installed via tar is to use a program such as ‘stow’, stow installs the package to a separate directory (/opt/stow/) for example and then creates links from the system to that directory as appropriate. Stow requires that you have Perl installed and is available from: http://www.gnu.ai.mit.edu/software/stow/stow.html.

Command	Function
tar -tf filename.tar	Lists files in filename.tar
tar -xf filename.tar	Extracts files from filename.tar

Checking file integrity

Something I thought I would cover semi-separately is checking the integrity of software that is retrieved from remote sites. Usually people don’t worry, but recently ftp.win.tue.nl was broken into, and the TCP_WRAPPERS package (among others) was trojaned. 59 downloads occurred before the site removed the offending packages and initiated damage control procedures. You should always check the integrity of files you download from remote sites, some day a major site will be broken into and a lot of people will suffer a lot of grief.

RPM integrity

RPM packages can (and typically are) PGP signed by the author. This signature can be checked to ensure the package has not been tampered with or is a trojaned version. This is described in great deal in chapter 7 of “Maximum RPM” (online at http://www.rpm.org/), but consists of adding the developers keys to your public PGP keyring, and then using the –K option which will grab the appropriate key from the keyring and verify the signature. This way, to trojan a package and sign it correctly, they would have to steal the developers private PGP key and the password to unlock it, which should be near impossible.

Be warned however there are some potential problems if you do not configure RPM correctly. Please see this security advisory:

https://www.seifried.org/security/advisories/kssa-001.html

dpkg integrity

dpkg supports MD5, so you must somehow get the MD5 signatures through a trusted channel (like PGP signed email). MD5 ships with most distributions.

PGP signed files

Many tarballs are distributed with PGP signatures in separate ASCII files, to verify them add the developers key to your keyring and then use PGP with the –o option. This way to trojan a package and sign it correctly, they would have to steal the developers private PGP key and the password to unlock it, which should be near impossible. PGP for Linux is available from: ftp://ftp.zedz.net/.

GnuPG signed files

Also used is GnuPG, a completely open source version of PGP that uses no patented algorithms. You can get it from: http://www.gnupg.org/.

MD5 signed files

Another way of signing a package is to create an MD5 checksum. The reason MD5 would be used at all (since anyone could create a valid MD5 signature of a trojaned software package) is that MD5 is pretty much universal and not controlled by export laws. The weakness is you must somehow distribute the MD5 signatures in advance securely, and this is usually done via email when a package is announced (vendors such as Sun do this for patches).

Automating software updates

NSBD

NSBD (not-so-bad-distribution) is a method to autmatically distribute and update software securely over the network. You can get it from: http://www.bell-labs.com/project/nsbd/.

Automating updates with RPM

AutoRPM

AutoRPM is probably the best tool for keeping rpm’s up to date, simply put you point it at an ftp directory, and it downloads and installs any packages that are newer then the ones you have. Please keep in mind however if someone poisons your DNS cache you will be easily compromised, so make sure you use the ftp site’s IP address and not its name. Also you should consider pointing it at an internal ftp site with packages you have tested, and have tighter control over. AutoRPM requires that you install the libnet package Net::FTP for Perl and is available from: http://www.kaybee.org/~kirk/html/linux.html.

RpmWatch

RpmWatch is a simple Perl script that will install updates for you, note it will not suck down the packages you need so you must mirror them locally, or make them accessible locally via something like NFS or CODA. RpmWatch is available from: http://www.iaehv.nl/users/grimaldo/info/scripts/.

Automating updates with dpkg

Debian's software package management tools (dpkg and apt-get) support automated updates of packages and all their dependancies from a network ftp server. Simple create a script that is called by cron once a day (or more often if you are paranoid) that does:

#!/bin/bash
PATH=/usr/bin
apt-get update
apt-get upgrade

The only additional thing you will need to do is configure your download sites in /etc/apt/sources.list and general apt configuration in /etc/apt/apt.conf.

Automating updates with tarballs / tgz

No tools found, please tell me if you know of any (although beyond mirroring, automatically unpacking and running “./configure ; make ; make install”, nothing really comes to mind, i.e. a ports collection similar to BSD).

Tracking software installation

Usually when software installs from a source install as opposed to a package it has a tendency to go all over the place. Removing it can be an extremely troublesome task.

instmon

instmon is run before and after you install a tarball / tgz package (or any package for that matter). It generates a list of files changed that you can later use to undo any changes. It is available from: http://hal.csd.auth.gr/~vvas/instmon/.

Converting file formats

Another way to deal with packages/etc. is to convert them. There are several utilities to convert rpm files to tarballs, rpm’s to deb’s, and so on.

alien

alien is probably the best utility around for converting files, it handles rpm’s, deb’s and tarballs very well. You can download it from: http://kitenet.net/programs/alien/.

Finding software

One major problem with Linux is finding software that did not ship with your distribution. Searching the Internet is a pain. There are some resources however that can ease the pain:

Secure programming

This whole guide exists because Linux and the software running on Linux systems is either insecurely written, or insecurely setup. Many issues, such as buffer overruns, are due to bad programming and carelessness. These problems become especially bad when the software in question is setuid to run as root, or any other privileged group. There are a variety of techniques, and other measures that can be taken to make software safer.

Secure Linux Programming FAQ

This guide covers a lot of general techniques for secure programming as well as some Linux specific items. You can get it at: http://www.dwheeler.com/secure-programs/.

Secure UNIX Programming FAQ

This document covers a variety of techniques to make programs more secure, as well as some pretty low level items like inherited trust, sharing credentials, and so on. This document is available at: http://www.whitefang.com/sup/ and I highly recommend reading it if you plan to program in Linux (or UNIX in general).

Secure Internet Programming

Secure Internet Programming (SIP) is a laboratory (for lack of a better word) that studies computer security, and more specifically problems with mobile code such as Java and ActiveX. They have a number of interesting projects going, and many publications online that make excellent reading. If you are going to be writing Java code I would say you have to visit this site: http://www.cs.princeton.edu/sip/.

Writing Safe Setuid Programs

Writing Safe Setuid Programs is an extremely comprehensive work that covers most everything and is available in HTML format for easy reference. A must read for anyone that uses setuid software, let alone codes it. Available at: http://nob.cs.ucdavis.edu/~bishop/secprog/

userv

userv allows programs to invoke other programs in a more secure manner then is typically used. It is useful for programs that require higher levels of access then a normal user, but you don't want to give root access to. Available at: http://www.chiark.greenend.org.uk/~ian/userv/.

Testing software

There are a variety of common errors programmers make that leave software vulnerable to attacks. There are also tools to help find these problems and show the existence of other issues.

fuzz

Written by Ben Woodward, fuzz is a semi-intelligent program that feeds garbage, random, and other pseudo-hostile inputs and sees how the program reacts (i.e. does it dump core and have a heart attack?). fuzz is available from: http://fuzz.sourceforge.net.

Compiler patches

There are several sets of patches for compilers to increase security.

Stackguard

Stackguard is a set of patches for GCC that compile programs to prevent them from writing to locations in memory they shouldn't (simplistic explanation, the Stackguard website has much better details). Stackguard does break some functionality however, programs like gdb and other debuggers will fail, but this is generally not a concern for high security production servers. You can get Stackguard from: http://www.immunix.org/.

Back

Last updated on 1/9/2001