Questions and Answers
Bjorn Satdeva
During the past couple of months, I received a large number of sendmail questions. Rather than answer the questions one by one, I decided to give an overall introduction to the topic. Yes, sendmail is a pain in the neck from the point of view of security. However, there is, in my experience, no better software available to handle what sendmail does: deliver email. And, there are a number of ways to minimize the security risks. First of all, unless you are in an environment where mail is delivered to the desktop, you do not need to run an active sendmail on all of your machines. On the machines that do not need to receive mail, change sendmail so it no longer listens to the network for connections. This is done by editing the rc file that starts sendmail, removing the -bd option, and installing a client sendmail configuration file (I'll explain how to build it below). After this change, the start of sendmail in your rc file should look something like this:
sendmail -q30m
When you remove the -bd option, sendmail will no longer run in daemon mode, or, as mentioned above, no longer listen to the network. This eliminates the possibility of remote sendmail attacks on all hosts where this change is made. The sendmail client configuration will ensure that the machine will still be able to send mail. On the machine where users are reading mail, you cannot make the above change, but you can still eliminate the possibility of nearly all remote attacks by downloading the firewall tool kit and installing the programs smap and smapd. Smap is a program that, like sendmail running in daemon mode, listens to the network and accepts SMTP connections from remote hosts. However, unlike sendmail, smap is running in a chroot'ed (change root, see man page for chroot utility) environment. When smap starts up, it will do a chroot to its spool directory and will simply drop all incoming messages as files in that directory. Even if somebody is able to break the program, there is not much they can do thereafter. The companion program, smapd, will pick up the files and use sendmail to deliver the mail to its destination. Before sendmail is invoked, however, all shell meta characters (if any) are replaced by shell comment symbols (#), effectually eliminating nearly all mail header attacks. And, sendmail will deliver the mail to the destination, using the usual rules specified in its configuration file, so everything appears to be working as before. (Except now there are a lot more hops involved, so increase the hop count in your sendmail configuration.) With these changes in place, you have probably eliminated many of the possible remote attacks that attempt local access through the SMPT port. These changes, however, will not eliminate any of the possible local attacks, so you will still need to be on your toes and update sendmail when the sendmail security patch of the month comes coming out. Unfortunately, there is no good universal solution to this problem, but at least people will need local access to utilize these types of security holes. Depending on your site, however, this may not be much of a consolation. Understanding and creating the sendmail configuration file is yet another big headache. However, as I have previously mentioned in this column, Eric Allman has created a configuration tool using the M4 preprocessor, which eliminates most headaches in building sendmail configuration files. It has been my experience that sendmail configuration files can be built for most systems, without having to write a single line of sendmail macros. Instead, the configuration file is built using a (usually low) number of M4 macros. For example, the M4 configuration for the sendmail file used on my mail server looks like this:
include(`../m4/cf.m4') VERSIONID( $Header: /usr/share/sendmail/config/RCS /server.mc,v 1.1 1996/12/16 22:10:40 bjorn Exp bjorn $ )dnl OSTYPE(`bsdi2.0')dnl DOMAIN(`generic')dnl define(`SMART_HOST', `smtp:mailrelay.sysadmin.com') MASQUERADE_AS(`sysadmin.com') EXPOSED_USER(`root postmaster hostmaster webmaster') MAILER(local)dnl MAILER(smtp)dnl define( `confMAX_HOP', 27 )
This file will build the complete sendmail configuration file necessary for a mail hub, when expanded with M4:
m4 < server.cf > sendmail.cf
You will need to substitute these values with the ones that fit your specific site; specifically, the MASQUERADE_AS and probably the OSTYPE must be changed to your local values. Similarly, a configuration file for the client will look like this:
VERSIONID(`@(#)clientproto.mc 8.6 (Berkeley) 8/16/95') OSTYPE(`bsdi2.0')dnl FEATURE(nullclient, mailhost.$m)
This M4 configuration file will build the absolute minimal sendmail configuration, which does nothing but forward the mail to the mail hub. This configuration file must be used on the sendmail client I mentioned in the beginning of this overview. Both the Sendmail book (by Costales, Allman, and Rickert from O'Reilly and Associates) and the README file in the sendmail distributions cf directory contain detailed information for each of the M4 macros, so I will only mention some of the most important macros: OSTYPE: This macro includes all the OS-specific information, such as location of the spool directory, help files, and user mailboxes. It must always be included. If you omit it, you will get an error when you try to build the configuration. DOMAIN: This macro includes definitions that are specific to your domain. You can build your own definition file, but for many installations, the generic definition may be suffcient. If you need to support multiple subdomains, you should define this on all inside machines, but leave it undefined on the outer machines. SMART_HOST: This is necessary for sites that are either not connected directly to the Internet (such as UUCP sites), or that have an application proxy style firewall. The SMART_HOST must point to the host that knows how to deliver mail to the world at large. MASQUERADE_AS: This M4 macro causes all outgoing mail to apear to come from the domain specified. By setting this to your domain, email will appear uniformly to come from your domain rather than from the individual hosts within the domain. This will simplify administration of replies to mail sent by users at your site. MAIL_HUB: This causes all mail to be sent to the machine defined here; it is useful when a central mail hub is used. EXPOSED_USER: These are special users, when you want to know exactly from which host the email originated. root and postmaster are two examples you normally want to have in this group. MAX_HOP: This is the maximum number of intermediate hops that will be allowed before mail is returned. By default, sendmail will return mail after 17 hubs, but if you are using an SMTP proxy, such as smap, the hop count can easily exceed this, so increasing it (to 27, for example) will eliminate this problem. You do not want this number to be too big, because you want to detect mail loops as early as possible (that is why the hop count is there in the first place). If you are running an older version of sendmail, I strongly recommend an upgrade to the latest version. The current version at the time of this writing is 8.8.4. The CERT mailing list will normally issue alerts when a sendmail problem has been discovered. You can subscribe to the CERT mailing list by sending email to: cert-advisory-request@cert.org. You can also find the old CERT advisories either on the CERT ftp server or at the system administration archives:
ftp://ftp.sysadmin.com/pub/admin /alert/cert
Although the information above is sufficient to configure sendmail, it will not be enough to diagnose problems. The errors users now get from sendmail are a lot less cryptic that they were 10 years ago, but it is still not easy for people new to sendmail to decode them. If you find yourself in that situation, then there are three things you need to look at. First, look at the return mail you get from sendmail. Look for the reason why the mail has been returned. Second, look at the mail headers of the returned message. This will show you the hosts the message has passed on its way before it was returned. Finally, look at the mail log, where crucial information can sometimes be found. But most importantly, get the Sendmail book mentioned above and start reading about how sendmail's inner parts work. Note that I have not mentioned anything about the syntax and semantics of the sendmail configuration file. The reason is that today many people are able to get by without ever writing a single line of native sendmail.cf code. However, it is still a very good idea to get a general understanding about the syntax and the principle on which the configuration file is based. If you don't, it will be more difficult to determine whether a problem is caused by a bad configuration file or a misconfigured name server. So, if you have not done so already, get Sendmail and start reading. And now here is the only question I received this month that was not about sendmail:
:tag num_init
and vi will take you to the desired place. Ctags understands C, Pascal, Fortran, YACC, lex, and lisp sources (but not Perl). However, ctags will not do everything you are asking for, as it is limited to function names. There some freely available programs that build the cross references you want, but they all very old, and the C language has undergone a number of transitions since these programs were written. If you are interested in having a look at them, they can be found at:
ftp://ftp.sysadmin.com/pub/admin/usenet/comp.sources.unix \ /volume1/cxref.gz
and
ftp://ftp.sysadmin.com/pub/admin/usenet/comp.sources.unix \ /volume11/id
If these don't work for you, you will need to turn to one of the many commercial development tools.
About the AuthorBjorn 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.
|
I read your column every month, and although this isn't strictly a sys admin question, I hope you can help. I need a general cross-referencing tool for C files. I want to supply a C file and have the tool spit out the names of functions and globals defined and referenced within the file (preferably one that can handle pointers to functions, too). Do you know of such a beast? I'd be much obliged.
You are not stating for what purpose you need this tool. If it is for interactive usage during an editing session, you can use the ctags file, which will be used by vi (actually ex) to find the location of functions and variables. After creating a tag file with the ctag program, you can jump directly to the function (e.g., num_init) you want by giving the command,