Click on our Sponsors to help Support SunWorld
Security: Pete's Wicked World by Peter Galvin

What's the Plan?

Get a grip on improving security through a Security Plan

September  1995
[Next story]
[Table of Contents]
Subscribe to SunWorld, it's free!

Last month we examined the security audit as a tool for determining the security state of your system. This month we will take the next step and plan actions based on those findings. The actions range from the minimal ("everything is fine") to the extreme ("unplug and spend a lot of money"). How can you determine the right course for your site? (1,500 words)

Also in Pete's Wicked World this month: the cornerstones of the security reading list and our first bug-of-the-month.

Mail this
article to
a friend

The security of your systems should not be taken lightly. A well thought out plan will help you reach your security goals. You need to determine, either formally or informally, the level of security you want to achieve and then plot a course of action. Your plan can simply be to maintain the status quo, but after auditing your systems that's not likely to be the case. Perhaps you'll decide to educate users, close known security holes, install a firewall, or revamp your entire installation. A plan is the first step in this direction.

The good news is by doing a security audit you have already implemented phase 1 of the plan (if you haven't performed an audit, consult last month's column). During the audit the need was for documenting your system configuration, deciding what aspects to examine, and performing the necessary evaluation. Now the plan can be expanded to include the findings of the audit and the important decisions made based on those results.

Let's start our plan by considering the issues raised last month. How do each of these relate to your environment? If one is a non-issue, just ignore it. Reduce this list to the set of problems you need to address at your site:


For each pertinent item, describe the current system state and the goal. Next month we'll look at the tools that could be used to reach that goal. There is an aspect of system changes that is sometimes overlooked: how changes will effect users. Once I have a set of problems and possible solutions, I try to get buy-in from the user community. Given the current state of computer security, users unhappy with restrictions being forced on them can find ways around them. Consider workers who put Post-it notes containing their passwords on their machines. Or the users that share an account because the system policies won't let them share files between accounts.

The more users are educated about a decision and the more input they have, the more they'll help -- rather than hinder -- your efforts. Have a meeting or circulate a memo describing:

Of course such an approach is not always possible, but in environments where it is feasible, it can prove invaluable.

For each of the above issues, consider your options:

With the audit and plan done, you know the current state of your site and the goal. With the proper tools and knowledge, the site security can be improved to meet the goal.

SUBHEAD Bug of the Month Club

The bug-of-the-month club covers security bugs that you may need to know about. This month's victim is the crash command on all versions of Solaris 2. crash is a program that helps analyze system memory images of running or crashed programs. crash, out of the box (or off the CD, really) is setgid sys. That is, its group has the setgid bit set, as shown by an "s" in the permissions field of ls -l output. The result is that when crash is run, it elevates the users to be a member of group sys. Unfortunately, the kernel memory devices /dev/mem and /dev/kmem are readable by group sys. The net result is that crash can be used by any user to read from the kernel's memory.

Reading kernel memory is a security hole because user passwords are stored there while they are typed, chunks of kernel memory hold program text and data blocks, and network packets are buffered in kernel memory as well. Hackers could use the information gained through crash to gain considerable information about your system.

To solve this problem, use chmod to remove the setgid bit from the executable (in this case, on machine mickey):

mickey# chmod g-s /usr/kvm/crash

SUBHEAD The Bookstore

Security, perhaps more than any other system-administration area, is rife with books. This is a good thing because, as it turns out, there's a lot to know about security, from a lot of angles. I've read some, skimmed more, and avoided a lot. Feel free to send me the names of any that you feel are worthy, and I'll add 'em if I like 'em. Here is the start of a list of books you should consider adding to your library:

Next Month, on "As Pete's Wicked World Turns"

Next month we'll delve into the tools available to help secure your systems, including a detailed look at several of them describing what they are good for and where they fall short.

Click on our Sponsors to help Support SunWorld


About the author
Peter Galvin is Chief Technologist for Corporate Technologies, Inc., a new Systems Integrator. He is also Systems Manager Emeritus of the Computer Science Department at Brown University. As a member of the Board of Directors of the Sun User Group, and has been Program Chair for the last four SUG/SunWorld conferences. As a consultant and trainer, he has given talks and tutorials world-wide. He has written articles for Byte and Advanced Systems (SunWorld) magazines, and the Superuser newsletter. Peter is coauthor of the best-selling Operating Systems Concepts textbook. Reach Peter at

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
-Too long
-Just right
-Too short
-Too technical
-Just right
-Not technical enough

[Table of Contents]
Subscribe to SunWorld, it's free!
[Next story]
Sun's Site

[(c) Copyright  Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact

Last modified: