Sysadmin stew: My summer vacation
We catch up on PGP, sysadmin tools, and
Once a year, SunWorld's editors indulge me as I offer "softer" commentary about management, the state of the union or dissolution of the union in system management, or some other area removed from the Unix command line. This month, I present a trip report -- not of my actual summer vacation, but of the research roads traveled answering reader e-mail and exploring interesting pieces of Internet flotsam and jetsam. I'll do this in true trip report fashion, with numerous bulleted lists connected by topic. Welcome to the USA Today version of Sysadmin. (2,500 words)
Instead of the usual background, exposition, and tips sections, we'll revisit four areas covered by columns of the past year. We'll start with a brief PGP update with both good and bad news for the PGP-literate public. From there we'll do a roundup of some security issues and "seat wrench" type tools -- those utilities that lay around unnoticed until you absolutely, positively need them, and you find that the tool is a perfect fit for the job. (For the uninitiated in home plumbing experiments, a seat wrench exists to do nothing else but remove the inner workings of a leaky faucet.) We'll close out this odd lot with some kind and not-so-kind words for our readership, our collective management, and marketing people cruising in the stratosphere of Internet hype. Read to the end to see who gets what on their plates.
Pretty Good gets pretty much better: A PGP update
Back in February, we covered Phil Zimmermann's Pretty Good Privacy (PGP) package, explaining how to use it to encrypt files and mail, and to use it as the basis for a digital signature and authentication scheme. At the time, Zimmermann was facing Federal prosecution in the United States for allegedly violating an export embargo on the PGP software. Rumors were rife about an upcoming PGP 3.0 release, and one major stumbling block for widespread use of PGP was the lack of a scalable, global, trusted key management scheme. Six months later, the news is mostly good:
premailutility to the rescue. This publicly available tool solves the problem by interposing itself between your mail user agent and the mail delivery agent, applying the PGP magic once you hand the mail off for delivery. Currently, premail works with any system using sendmail, or those who use Netscape 3.0 or Pine as mail user agents. An even simpler solution is
privtool, a look-alike for Sun's desket mail tool. It's not a complete functional replica, but it does move the PGP steps into the mail user agent instead of an intermediary that you must configure for each user.
Key management remains an open issue for PGP and other services that depend on public keys, such as Sun's Simple Key Management for IP (SKIP) protocol used by the Solstice SunScreen SPF-100 product. Rather than relying on a well-known service or hierarchy of key servers like the Domain Name System (DNS), PGP refers to a key ring maintained somewhere within your filesystem hierarchy. In essence, you take full personal responsibility for collecting and packing the keys you'll need. Generally, you'll add keys to your own keyring if you can prove the identity of the person giving you the key, for example, she hands you the key on a floppy disk while you sip double lattes.
Alternatively, you may accept an electronic copy of a key if it was digitally signed by one or more people to whom you would extend your trust. What you're saying is "I proxy my background check on this key to Bob and Fred; if they signed the key then I will believe it's valid, even if I don't know the key holder personally." Dealing with PGP keys from users you haven't met poses a non-trivial problem.
The USENIX Association offers a key-signing service to help build a web of trust between its members. Operationally, the signing service is elegant in its simplicity. Any USENIX member presents him or herself at the USENIX booth at an industry conference or show, provides two forms of identification, at least one with a picture, and agrees to indemnify USENIX for any misuse of the PGP keys. At the time this agreement is signed, a USENIX representative gives you a "shared secret" containing some sequence information and eight words. The key signing is done electronically, via e-mail, using the shared secret to reconfirm the identity of the human being present at the USENIX booth. You'll need the 1996 USENIX key-signing key, available on the USENIX Web site. Once your sign bits have USENIX written on them, use the Web query interface to find a particular user's key.
Two shameless plugs on behalf of USENIX: First, join if you're not already a member. In addition to the USENIX organization proper, there's the System Administrator's Guild (SAGE), the largest professional organization devoted solely to systems management. Second, the 10th Systems Administration Conference (LISA '96) will be held September 29 through October 2 in Chicago. Get signed, learn something at the same time, and meet your peers in the industry.
Dropping the security blanket
We'll use the preceding good news about PGP and key signing as an opening act for some more somber and pragmatic news on security issues:
pgpcrackfloating around the Web. As its name implies, it's a brute-force attack on PGP encrypted files. With the exponential rise in networked computing power available, it's not unreasonable to think that some PGP encryption can be cracked. Word to the cautious: use the largest PGP key sizes (1024 bits) if you fear the sledge hammer approach.
It appears that MD5 can be abused such that a given document may be modified into another, different document that aliases to the same MD5 checksum. The likely successor to MD5 is the NIST Secure Hash Algorithm (SHA-1), with a fast implementation described in a conference paper (see the Resources section below for the URL).
vold), /etc/rmmount.conf, and the temporary files used to inform the Solaris desktop file manager that a new media volume has been loaded. The temporary files created by the volume manager are not handled in a secure way, and could allow arbitrary files on the system to be accessed by the volume manager daemon, which of course runs as root. The suggested fix (short of not running the volume manager) is to comment out the lines in /etc/rmmount.conf that create these temporary files:
action cdrom action_filemgr.so action floppy action_filemgr.soInsert a hash mark (#) at the beginning of these two lines to disable the file manager notification.
checkXusersthat looks for users logged in from X servers that have relaxed their authorization, opening up potential holes to the local system.
netstat(which must be in your path) and should be run as a normal user.
crack, it is meant to be flexible and quick, and it can also make use of multiple hosts at once to reduce the time required to iterate through the guessing game. Use
crackto pro-actively ferret out weak passwords, and then annoy users to change them. This is a simple case of arming yourself with the same tools available to anyone who has a more sinister interest in obtaining passwords to your systems. Rather than go through a password change-filter-harass cycle repeatedly, you may want to run passwords through the guessing rules when they're first entered by the user, at the time the password is set or changed. Voila
cracklib, a C-callable library that mimics the functionality of
crack. Use it in a wrapper around
yppasswdto enforce good password hygiene. Like it or not, passwords are a fact of life in a well-run environment. Even if you use PGP religiously, you need a password to unlock your private key (unless you're adept at memorizing 1024-bit strings). Passwords under your aegis should be well kept, well formed, and subjected to the most active filtering possible.
The COAST archives at Purdue University, home of the last two items mentioned, contain a plethora of security and network analysis tools. They're worth a visit during your Web travels.
Cool tools and jewels
Here are some other cool tools and management jewels proffered by gentle readers and not-so-gentle mailing lists:
xmove, available from both the X distribution site or Columbia University.
xscope (November 1995) pseudo-server that
intercepts X Window System client/server communications for debugging
xmove acts as a man in the middle that can
redirect a client's X requests to a different server. You create a
"fake" X server on your own machine using
direct your local X clients to it instead of the physical display.
Under normal conditions,
xmove passes the traffic right
through to the local screen, but when you tell
shift displays, it routes the traffic to another screen, on another
machine, effectively following you from hop to hop on your
Products like the Integrity Engine show what's possible when you treat your browser like the universal front end. Constantly emphasizing easy and simple access to data, however, may sometimes cloud the real underlying issues.
Return to zero logic: Costs of system management revisited
Tim Steele, a reader from the United Kingdom, chided me for "making [this] sound too easy", where "this" ranged from including PGP support in mail services to editing sendmail configuration files. After a few exchanges of e-mail, I concluded that Tim was right, and I have glossed over implementation details at times. When I go light on the content, it's for one or more of a few reasons: I may not have done it myself, or proven that an idea works; the details would require several dozen pages more than editorial prudence or deadlines allow; or I'm simply offering an idea for digestion, hoping that someone will return a useful pointer (such as the MKS Integrity Engine).
Tim's main point, however, was not to question the competence of himself or his peers, but to underscore that fact that management sees light treatment of a topic as an indication of trivial implementation. Setting proper time, cost, and complexity expectations for users and management has been a recurrent theme in this space. Unix system management expenses, along with mainframe operations or telecommunications costs, are not discretionary expenditures. They're a necessary component of a first-class, reliable operation.
Like mainframes, Unix sysadmins are not easily and safely modified to perform the function du jour; careful implementation of the latest ideas yields a performant and predictable system. Cost issues have sprung up with every new paradigm embraced by the technical press: PCs, client/server computing, and now even Internet access. It's important to focus on the cost of running the show, but it's even more critical to know what kind of show it is: a serious production or a casual operation. Careful design, architecture and implementation hold the costs down in the long run and generate positive value for the organization.
Why the rant? The trade press has been full of talk of Network Computers (NCs), proclaiming their costs of administration to be near zero. From an end-user perspective that may be true -- there's no need to load floppy disks or interfere with system configuration files each time you need a new application. But from the system and network management viewpoint, there's no such thing as a zero-administration device. Someone has to do the network design, performance and capacity planning, and network failure analysis, although that effort is likely to be more centralized than before.
Again, the comparison to mainframe operations is quite strong. Does Unix run the risk of becoming the next legacy environment, ridiculed for its antiquated ways? Hopefully not, since Unix has a long history of encouraging rapid innovation, rapid delivery of that functionality, and a skilled community of professionals -- our readers -- who are responsible for fueling the pace of that change. Realize what re-centralization of services means, and learn from what the mainframes do well and what they don't do so well. It's something to consider on your next vacation.
If you have technical problems with this magazine, contact email@example.com