Questions and Answers

Bjorn Satdeva

A number of people have written to me in response to my recent sendmail column (Sys Admin 6(3):75-78) and have pointed out two sendmail replacements, the GNU Smail and a newer software package called qmail. Although either of these packages may fit a local requirement better than the original sendmail, I am still of the opinion that neither is an adequate sendmail replacement.

I have been using Smail on and off over the years, and in my experience, Smail does not have anywhere near the same configurability as sendmail. This is normally not a problem in a smaller installation, but if a large site tries to go that route, they commonly end up having to run sendmail somewhere in order to resolve all their mail issues.

Qmail is still a very new package. When I looked at the package last time (a few months back), there were a number of recent bug fixes for general functionality. I have chosen not to test it until it becomes more stable.

Over the years, there have been a number of mail delivery agents that have attempted to replace sendmail, but none of them has so far succeeded.

For many system administrators, this issue involves both security and reliability. A mail delivery agent is solving a very complex task and is not easy to get right, as early versions of Smail and now Qmail are showing. Even with software that works correctly, it is not too difficult to misconfigure something so mail no longer gets delivered correctly. Some people have argued for a high-level configuration language. As far as I know, there has only been one attempt to provide a high-level sendmail configuration language and compiler. However, this package, called Ease, never got any widespread usage. Originally, the obscure configuration language for sendmail was chosen by Eric Allman, because it was fast to parse. This was an issue ten or fifteen years ago, but is hardly an issue on modern hardware. Eric considered using a high-level configuration language for sendmail when he wrote sendmail version 8. However, the current solution, which uses the M4 preprocessor, works almost the same.

The security issues for the mail delivery agent are also of major importance, and choosing a little known delivery agent does not mean that you have a secure solution. At best, you might have some security through obscurity, but I have heard of at least one system intrusion through Smail a few years back. For network security, so far nothing has proven to be a better solution than the Smap proxy that TIS distributes as part of the Firewall Tool Kit. You can install this proxy on a machine without using the rest of the toolkit. I would use this solution for both sendmail and Smail, and presumably it will work with Qmail as well.

Sendmail and host security present a different problem. This situation occurs when sendmail is used to become root on the local machine. However, sendmail is not alone here, there is a wealth of methods that can be used to achieve root on machines that have not been security hardened. While sendmail has a proven track record of being a security risk, it also has the advantage of being closely monitored by security-conscious system administrators. A case can be made for using one of the less common mail delivery agents, but personally, I would rather rely on this mechanism together with CERT and Eric Allman's bug fixes than on a package where it is less likely that I quickly will learn of problems. A system administrator who is responsible for a machine where this kind of security is an issue needs to stay informed by subscribing to several of the security mailing lists, paying close attention to the CERT announcements, and updating the software as soon as new versions are released.

The bottom line for me is that I will continue to use sendmail for now and use any additional security feature that I reasonably can. I do, however, reserve the option to change this at any time in the future, if any new data becomes available showing it would be good for my health as a system administrator to do so. Also, a specific need at a client site may result in my choosing to recommend another solution for that client's needs. You may disagree with me, and that is fine, as long as you have come to your conclusion through an analysis of the security requirements at your site. If there is one message I have tried to get across over the years, it is that when it comes to system administration and security, one size does not fit all.

I have a query that I think you are the right person to answer. I want to reserve all the free ports on the system. Unless it is defined in /etc/services, no user should be able to use the free ports except root. I will be very grateful for your answer.

I think there is a little bit of misconception here. The reserved ports are all ports below port 1024. A reserved port can only be opened by root. The information in /etc/services lists Reserved Ports as Well-Known Ports.

The only way you can prevent users from using ports above 1024 is to change the kernel. This not only requires you to have sources for the kernel, but will also cause you to break a number of programs (ftp is one example).

Also be aware that the reserved ports are a UNIX concept. Most other implementations do not honor this concept.

In your question you did not mention why you wanted to implement such a solution. It seems to me that you may be attempting to secure your network by preventing anybody from using ports other than the well-known ones. This is unlikely to work. First of all, it will require complex modifications to all of your systems, and will not prevent anybody from using a well-known port that is advertised in /etc/services but otherwise unused. Second, it will not prevent somebody, with for example a lap-top running Windows, from connecting from a port you believe to be secured through this scheme.

When attempting to resolve a security problem, it is important that the solution provides a contribution toward overall security. If it just makes the problem move to another place, it is at best security by obscurity and as such is often harmful.

I hope this is an easy question to answer. How do I make a multi-volume backup to floppy from a SunOS 4.1.4 system? I find myself responsible for distributing software. Some distribution media include ftp, 8-mm tape, and CDs. One distribution target can only accept floppies. My files are minimally 5 Mb in size.

There are two routes you can take. You can create a tar image on disk, compress and uuecode it, and then use split to break it up into chunks that will fit on your floppy, in email, or wherever the archive in question was too big.

For example, the commands:

% tar -cvf TAR.image /somewhere

% gzip TAR.image

% uuencode TAR.image.gz < TAR.image.gz > TAR.uu

% split -l 24000 TAR.uu TAR.uu

will create a number of files, where the name of the first output file is TAR.uu with aa appended, the second file is TAR.uu.ab, and so on. The above example can also be done in a single pipe:

% tar -cvf - /somewhere | gzip | \

uuencode TAR.image.gz | split -l 24000 - TAR.uu

To restore the file, you will need to restore each of the pieces, then use the cat program to piece them into a single file, which must be decoded and uncompressed before it can be restored:

cat TAR.uu.* | uudecode | gzip -d | tar -xvf -

The above will work nicely if you are in a tight spot and is a technique that should be in every system administrator's tool box. However, it is not a strategy you want to use for day to day work. For this purpose, consider getting the GNU tar program, which I believe is able to use split images on most UNIX systems.

I am currently looking to replace our in-house backup scripts with an off the shelf solution. Do you know of any recent comparative studies of available options that would provide me with a short list. Thanks in advance!

If you are looking for freeware solution, then there are several backup managers available. You will find them all at the system administration archive at:

ftp://ftp.sysadmin.com/pub/admin/backup

We are using Amanda here, with good result. There are also several commercial solutions available. If you go that route, I suggest that you use a solution that implements an administrative front end to the usual UNIX backup programs, such as dump and tar. Such a solution has the advantage that you can always restore a tape using the UNIX utility directly. A solution that depends on a custom format may not offer you such advantages.

I'd like to rename an executable and replace it with a script that can do some security checks before allowing the original program to run. My problem is that I don't know how to protect the script so that the user doesn't see the renamed program.

Since a script must have both read and execute permissions, how do you give the general public execute capability while hiding text from curious eyes? Can a renamed binary ever be front-ended by a script in this way and be secure?

By definition, a script must be readable in order for it to be executed. It is possible to come up with a solution in which the text of the script is compressed, but your users can read the content by uncompressing the file. Perl at one time had an undisclosed feature that allowed it to execute encrypted programs, but I don't know of anybody who has used it, or if it still is supported. The traditional way to do what you want, is to write a wrapper in C. However, be aware that you will need to keep the original executable somewhere on your hard disk, in order for your C wrapper to find it. It will therefore not be difficult for a malicious user to find it too, and bypass the wrapper programs.

I work on several Unix platforms, and while some of the newer ones might have some built-in class/authority mechanism, most of the other SV4 systems don't. I can think of a few security holes this mechanism could plug, like su. Your comments would be appreciated.

Any feature that is provided by only a single vendor is of little interest to most sites, as most sites are heterogeneous in nature. Security in particular is a problem, but I have yet to see good general and widespread mechanisms of the type you are alluding to. Many vendor solutions are often targeted toward a single audience, such as classified systems or systems in traditional mainframe environments. Providing such solutions is fine, as long as they are not presented as solutions to everybody's problems.

About the Author

Bjorn Satdeva is the president of /sys/admin, inc., a consulting firm which specializes in large installation system administration. Bjorn is also co-founder and former president of Bay-LISA, a San Francisco Bay Area user's group for system administrators of large sites. Bjorn can be contacted at /sys/admin, inc., 2787 Moorpark Ave., San Jose, CA 95128; electronically at bjorn@sysadmin.com; or by phone at (408) 241-3111.