Written by Kurt Seifried
Automating updates with tarballs / tgz
Tracking software installation
RPM is a software management tool originally created by Red Hat, and later GNU'ed and given to the public (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.
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.
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 |
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 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.
dpkg supports MD5, so you must somehow get the MD5 signatures through a trusted channel (like PGP signed email). MD5 ships with most distributions.
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/.
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/.
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).
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/.
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.
Rhlupdate will also connect to an ftp site and grab any needed updates, the same caveats apply as above, and again it requires that you install the libnet package Net::FTP for Perl and is available at: ftp://missinglink.darkorb.net/pub/rhlupdate/.
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/.
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, you can download it from: https://www.debian.org/Packages/stable/admin/apt.html.
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).
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.
installwatch monitor what a program does, and logs any changes it makes to the system to syslog. Its similar to the “time” program in that it runs the program in a wrapped form so that it can monitor what happens, you run the program as “installwatch /usr/src/something/make” for example (optionally you can use the “–o filename” to log to a specific file). installwatch is available from: https://datanord.datanord.it/~pdemauro/installwatch/.
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/.
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 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/.
slurp takes an interesting approach, it behaves somewhat like installwatch, but also has some of the features of alien. It monitors the system as you install a package, and creates an rpm file from this. You can get slurp from: https://students.vassar.edu/~jajohnst/slurp/.
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:
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.
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/.
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 (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 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://olympus.cs.ucdavis.edu/~bishop/secprog.html.
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/.
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.
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.
There are several sets of patches for compilers to increase security.
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/.
Stack Shield is an alternate method for protecting Linux binaries from buffer overflows, however I have not yet tried it. You can get it at: https://www.angelfire.com/sk/stackshield/.
| Written by Kurt Seifried |