By Kurt Seifried [email protected]
Introduction
Software package formats and the like.
RPM
RPM is a software management tool originally created by Red Hat, and later
GNU'ed and given to the public at https://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 https://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:
https://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 https://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: https://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: https://www.bell-labs.com/project/nsbd/.
Automating updates with RPM
Yum
This is the default tool for Red Hat Fedora Core Linux and is available on
other systems as well, it handles dependancies/updates/etc.
up2date
This is the default Red Hat tool, available for Red Hat Enterprise and Fedora
Core.
apt
apt is now available to handle rpm's.
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: https://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: https://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: https://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: https://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: https://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: https://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: https://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: https://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: https://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: https://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: https://www.immunix.org/.
