UNIX System Administration Handbook - Evi Nemeth [462]
• Who can have an account?
• What happens when they leave?
The resolutions of such issues need to be written down so that you can stay consistent and avoid falling prey to the well-known, four-year-old’s ploy of “Mommy said no, let’s go ask Daddy!” Often, the “if” portion is the policy and the “how” portion is the procedure.
Some policy decisions will be dictated by the software you are running or by the policies of external groups, such as ISPs. Some policies are mandatory if the privacy of your users’ data is to be protected. We call these topics “nonnegotiable policy.”
In particular, we believe that Internet addresses, hostnames, UIDs, GIDs, and usernames should all be managed on a site-wide basis. Some sites (multinational corporations, for example) are clearly too large to implement this policy, but if you can swing it, site-wide management makes things a lot simpler. Tools that facilitate the management of hosts and user accounts across administrative domains are available from the net. Our crufty old versions, addhost and adduser , are not sterling examples of the genre, but they’re still in use and are available from ftp.xor.com if you can’t find anything better.
We strongly believe that logins should never be shared. It is a lot easier to enforce this policy if the temptation to share is removed. We used to maintain a guest machine with a liberal account creation policy as an easy alternative to clandestine sharing, but now with free email accounts available from several sources (AOL, Hotmail, Yahoo, et al.) and public terminals everywhere (libraries, Internet cafes, etc.) we no longer find this service to be necessary.
Other important policy issues that may have a larger scope than just your local sysadmin group are:
• Handling of security break-ins
• Filesystem export controls
• Password selection criteria
• Removal of logins for cause
• Copyrighted material (MP3s and DVDs, for example)
• Software piracy
Maintaining good channels of communication among administrative groups at a large site can prevent problems and help to develop trust and cooperation. Consider throwing a party as a communication vehicle. Some sysadmin groups use an IRC-like MUD or MOO as a communication vehicle. It can get very chatty, but if used properly can make your organization run more smoothly, especially if some staff work off-site or from home.
Security policies
What do you want to protect? Your data? Your hardware? Your ability to recover quickly after a disaster? You must consider several tradeoffs when designing a security policy for your site:
• Services offered vs. security provided (more services = less secure)
• Ease of use and convenience vs. security (security = 1/convenience)
• Cost of security vs. risk (cost) of loss
RFC2196, the Site Security Handbook, is a 75-page document written in 1997 by a subgroup of the Internet Engineering Task Force (IETF). It advises sysadmins on various security issues, user policies, and procedures. It does not include a recipe for securing an Internet site, but it does contain some valuable information. The last 15 pages are a wonderful collection of both on-line and published references.
RFC2196 suggests that your policy documents include the following points:
• Purchasing guidelines for hardware and software. It can be a big win to involve sysadmins in the procurement process because they often know about hardware quirks, software limitations, and support issues that are not advertised by the vendors’ marketing teams.
• A privacy policy that sets expectations regarding the monitoring of users’ email and keystrokes and policies for dealing with user files.
• An access policy: who can have access, what they can do with their access, what hardware and software they can install, etc. This document should include the same warnings about authorized use and line monitoring that are included in the privacy policy.
• An accountability policy that spells out the responsibilities of both users and sysadmins.
• An authentication