|
What's the Plan?Get a grip on improving security through a Security Plan |
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.
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
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.
|
Resources
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 peter.galvin@sunworld.com.
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-09-1995/swol-09-security.html
Last modified: