New Messages
Subject: Sys Admin June 2000 Newsletter I've already cancelled my subscription because of your spam. Not a very smart thing to be sending spam to sysadmins. Now I'm actively convincing other sysadmins to also cancel their subscriptions & it's actually working. It wasn't hard to convince them since your spam already pissed them off, too.
Thanks for your input. I will admit that it surprises me. Many of Sys Admin's readers have told us that they consider the newsletter to be a valuable additional service. I am used to the term “spam” being used to refer to mass mailings to recipients that have no previous relationship to the sender. We don't do that. We are sending informational updates to existing customers who have supplied us with their email addresses. We realize that certain people would prefer not to receive these updates. That is why we have a clearly stated method at the end of each newsletter to unsubscribe. I am interested as to what aspect of this you find unacceptable. As more and more of what has been traditionally handled by snail-mail moves online, feedback from subscribers (or former subscribers) is very helpful for setting future policies and procedures. I would also be interested in hearing from the other sys admins you have spoken to.
Sincerely,
From: Will Waites <ww@shadowfax.styx.org> With respect to the article entitled “Setting Root SUIDed Programs at Work” by Didier Racheneur in the April 2000 issue of Sys Admin, I would like to point out a couple of issues that are glossed over or ignored. Several of the practices suggested in this article, in fact, would introduce significant security problems in a system should someone actually put them into practice. The “Build a Backdoor” sidebar: Using a simple checksum to verify that a password is correct is very dangerous. The reason passwords are verified against a hash generated using a modified version of DES or in some cases MD5 or Blowfish is because these are dense algorithms -- meaning that no two bits of cleartext will encrypt to the same ciphertext. The checksum algorithm used in this article does not display this behaviour. In fact, one simply has to iterate across strings with increasing checksums to find the correct password. In the case of “wait & 123SEE” a sequential searching of the keyspace requires only 910 iterations. It is clearly feasible for someone with a local account to gain superuser access in this manner. Even using a more secure hashing algorithm is arguably insufficient. Better to have a particular RSA public key in root's .ssh/authorized_keys file, which brings me to my second point: “Becoming Root without the Password”: Surely a magazine such as Sys Admin should not be counselling novice administrators to even use the old Berkeley r* services, let alone allow remote access to the root account using only .rhosts authentication. In many cases it is trivial to forge the source address of packets as well as the trust mechanism that lets the remote machine know the name of the user initiating the connection. A much better alternative is to use ssh with RSA keys. This provides much stronger authentication facilities and, though it is still possible to exploit, it is much more difficult. IMHO it is irresponsible to print articles that encourage sloppy security practices. Any novice system administrator reading this magazine in the hopes of finding useful tips could easily unintentionally open up their system to be cracked.
Regards,
We occasionally receive a brisk reminder that Sys Admin's role as a forum for working admins does not always align perfectly with its role as a dispenser of universal, state-of-the-art, UNIX advice. We really like it when sys admins tell us what they're doing, and our focus is not always on whether they're doing what we would be doing or whether what works on one network will work for everyone. The SUID program article discussed documented features of UNIX that, even if you don't use, you're better off at least knowing about. In this case, however, we regret not providing more context. The role of root is a very special and dangerous feature that underpins the whole UNIX security structure. One of the reasons why so many object to SUID programs is that they tend to muddle the clear lines for managing who has root and why. Clearly, the act of shifting root authority around is not for everyone, but then, the author didn't intend for these concepts to be used by everyone. These techniques are not for every network, and they are not the kind of thing novices should be messing with. We regret that we did not provide clearer warnings about the possible implications of SUID programs. The sidebar titled “Build a Backdoor” drew the most fire. As a matter of clarification, the author was using the term “backdoor” as an alternative means of entry to a local system and not, as it sometimes is used in Internet jargon, as a means of remotely accessing a network without passing the firewall. Although the text can be read as implying that this backdoor remedy is recommended for all cases, we believe the author's intent was to warn that, if you use SUID techniques to build such a program, you'd better make sure you protect it with password security. Even that may be too risky for many admins. This type of solution is intended for closed environments in which a roving admin must remember many root passwords and the computer can't be turned off. (Whatever you may think about this remedy, it is worth noting that a little blue notebook with 40 root passwords written in it is also a threat to security, as is a policy of setting the same password or password pattern for 40 different mission-critical servers so you don't forget what the root password is.) Readers' comments on encryption and other security matters are always welcome. Thanks for writing.
--The Editors
|