The SeOS security blanket
Product filters device & file access system calls,
A lot of time is spent in this column (and elsewhere) discussing various work-arounds, bug fixes, free tools, and commercial packages to increase the security of Sun machines. Unfortunately, almost all of these approaches fix only part of the problem, and until now none has fixed the fundamental problem. It's time to look at SeOS and see if it does the trick.
Also in Pete's Wicked World this month: S/Key is not secure, a warning about the location of CGI-script interpreters, and a PC-NFSD problem in the bug-of-the-month-club. In the bookstore, a pointer to a vulnerability database, a new mailing list, a new CERT activity summary, and a summary of an interesting network intrusion survey. (2,300 words)
It is becoming obvious that the current method of securing Unix generally and Solaris specifically isn't effective. New bugs are found, requiring new patches. You can weave a quilt of tools to monitor for intrusions and help prevent them. However, break-ins still occur and bugs still appear, seemingly with increasing frequency.
It is difficult to add security to a system that wasn't designed with security in mind. Unix exposes fundamental facilities, such as system calls and the set-uid mechanism, to applications and users. If programs and users are not well controlled, they can use these facilities and others to violate your security policies.
The solution is to rewrite Unix, by
Apparently, this isn't very easy, or all the Unix vendors would have done so. It might be time to stop waiting.
Rather than rewrite all of the Unix implementations, consider instead stealing their security-related system calls. Why not intercept all of the device and file access system calls and redirect them through our policy implementation? No matter how the system call is being made (a system program, a commercial application, or a user's program), the control is the same. Also, add a secure layer that allows the rules to be communicated between machines, so security can be centrally administered.
SeOS (SEcurity for Open Systems) from Memco Software implements this paradigm. Memco goes to the heart of the matter by intercepting system calls on a variety of platforms, and making the operating systems more secure. Essentially, SeOS adds a thin layer -- a security layer between the important system calls and their implementation. It does not modify the kernel itself, so it is fairly non-invasive.
SeOS consists of the core access control tool plus the following four components:
Fundamentally, SeOS provides a manageable access control list (ACL) facility to allow the security manager to write rules dictating which users or hosts can use which facilities. The ACLs can be conditional, with conditions including the date and time, the terminal in use, or the program being executed. Roles are defined by grouping users and resources.
It also supports multiple security "domains" (i.e., "financial" and "development"). Client machines subscribe to a specific domain, and any changes to the security model for that domain are sent to all domain subscribers. The security model can effect the following aspects of system operation:
su's to root are allowed only for authorized users. All root operations are logged, with the user's real identity indicated. set-uid programs are protected by being "thumbprinted" -- if the thumbprint changes the program is no longer executable.
At the heart of SeOS is an open API that allows applications to define their own resources and use the rules database to control security. Programs calling this API can take advantage of the GUI-based management tools and the reliable logging and auditing as well.
SeOS also implements a kerberos-based single sign-on. This eases the user's task buy decreasing the number of passwords users need to type and the frequency in which they are used. It also increases security by limited the number of passwords sent across the network, and improves auditing and logging accuracy.
One last SeOS feature is reliable and secure logging and auditing. Events can be recorded on success, failure, or not at all, as customized by the security manager for the given resource. The audit log is managed by a flexible GUI tool.
SeOS requires X11R5 for its GUI, and runs on AIX, SunOS and Solaris, and HPUX.
SeOS solves some of the long-standing security weaknesses inherent in Unix, and does so thoroughly, gracefully and conveniently. It's definitely worth a look for use in sites trying to get security, authorization, and authentication under control.
Bug of the Month Club
Bug of the Month Club
monkeyis to S/Key as
crackis to standard Unix passwords. That is,
monkeytakes as input a sniffer log or an
skeykeysfile and uses a dictionary to try to guess the secret key. The result is that S/Key secret keys are potentially guessable. S/Key is still more secure than sending reusable passwords across the Internet, but it cannot be depended on when password sniffing is possible.
monkeywas reported on the best-of-security mailing list. (Send subscription requests to firstname.lastname@example.org, or for a digest form to email@example.com.
The second is a security problem associated with Web sites and
CGI-scripts. It is vital and CGI-script interpreters (for instance,
perl program if CGI scripts are written in
perl at your site) be placed in a directory other than your
CGI-bin directory. Programs in the CGI-bin directory can be executed
with arbitrary arguments by anyone with Web-browser access to your
site, so placing any programs in this directory are a security risk.
The only files that should be in the CGI-bin directory are the CGI
scripts themselves and the bits they need for execution. No general
purpose programs should be in there.
CERT offers more details on the
security risks of CGI-script interpreters.
The final bug this month has to do with PC-NFS. Specifically, the pcnfsd daemon (which handles printing but not NFS itself), is vulnerable in multiple ways. It can use used to change any directory to be world-writable, and can also be used to gain root access on the server it on which it runs. The CERT pcnfsd advisory doesn't list SunOS or Solaris as being vulnerable to the bug, but if you run this daemon you need to be sure.
The Computer Security Institute publishes surveys that track computer usage and associated security aspects. A new report: The 1996 Computer Crime and Security Survey was just released and makes for very interesting reading. The survey was sent to security practitioners in a variety of U.S. businesses, government agencies, financial institutions and universities. Responses were obtained from 428 organizations.
Some of the highlights are:
The full report gives more details, and can be of use to security folks who need to light a fire under management to all them to get their security house in order.
A security vulnerability database
Also of interest is a security vulnerability database being put together by ISS. Here is the announcement:
We have begun putting together a vulnerability database on our web site at www.iss.net. This is still under construction, but we have started with network vulnerabilities and we will be expanding to include more system level vulnerabilities.
Each vulnerability has information regarding:
This database has just begun and does not contain complete information about all vulnerabilities.
- What the exploit vulnerability is?
- How to fix the vulnerability?
- Other references for more information, ie CERT advisories, CIAC, etc.
If you see a mistake or a suggestion, please email firstname.lastname@example.org.
Keeping up with CERT
CERT has released a new
It appears that the most common break-in methods are among the oldest,
so you should review the summary and verify that you've taken
precautions against these obvious methods. Toping the list is
crack being run against captured password files to allow
normal user access, then use of other known bugs to penetrate the
target system as root.
Next on the list is break-ins of Linux machines. These machines are commonly installed by non-professionals (read: hackers) and may be lacking in their security configuration. Why is this of concern to system administrators of Sun machines? Chances are, you have Linux machines co-resident on your networks. Are you trusting these machines? Would a broken Linux machine that is running a packet sniffer capture passwords to important computers on your network? If so, it is best to get those Linux boxes under control.
Also on the CERT summary list is the use of tools to search for weaknesses in target sites. ISS is a common tool to have pointed at you. Lastly, mail spoofing, bombing, and spamming are getting more common (and more annoying). What ever happened to good news?
This month Douglas Stuart sent mail regarding his experiences implementing the
smrsh secure shell for
sendmail that was recommended here a couple of months
ago. Douglas works at an ISP that has implemented
The biggest obstacle to using smrsh at my ISP was having to change the .forward files for those using procmail. The recommended .forward file in the procmail FAQ is:"|IFS=' ' && exec /var/adm/sm.bin/procmail -f- || exit 75 #douglas"The IFS part is unnecessary with procmail I'm told, and the
|| exit 75part is only necessary for systems with unreliable NFS servers.
After I've edited everyone's.forward files and fixed them I'm planning turn smrsh back on here.
Thanks for the comments.
Next Month, on "As Pete's Wicked World Turns"
Next month we'll look at the new Solaris ACL facility.
About the author
Peter Galvin is Chief Technologist for Corporate Technologies, Inc., a Systems Integrator and VAR. He is also Adjunct System Planner for the Computer Science Department at Brown University, 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 on the topics of system administration and security. 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 email@example.com.
If you have technical problems with this magazine, contact firstname.lastname@example.org