The SeOS security blanket Product filters device & file access system calls, scrutinizes them for malicious behavior.

July  1996

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)

Mail this article to a friend

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

• Changing all system calls that allow access to fundamental facilities.

• Adding ways to manage the system calls and control who can use them and the resources on which they can be used.

• Making the root user accountable by who it is that became root and what they did.

• Controlling set-uid and set-gid so only the programs that you intend to use this facility are allowed to.

• Logging system activities in a secure way.

• Allowing policy to be set on one machine and distributed to others.

• And while all the Unix vendors are rewriting their operating systems to be more secure, they should use the same interfaces and methods. Then, a policy set on one machine could effect security on many machines, no matter the operating system.

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:

• Account Manager to administer user account and resource profiles
• Administrator to define access permissions for resources
• Security Policy Wizard to ease policy definitions
• Auditor to provide interactive audit trail analysis

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:

• Login Restrictions SeOS can dictate who may login, from where, using what protocols, when, and for how long. This is full access control.

• Password Quality Customizable rules dictate password length, use of non-alphabetic characters, and aging.

• Authentication Users can be authenticated using standard re-usable passwords and a modified S/Key, and SeOS is compatible with all other authentication methods (smart cards and biometrics for instance).

• SuperUser ID Protection Root login is disallowed, and 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.

• Multiple Root Levels Even as root, a user's abilities can be segregated and limited using SeOS's ACL facility. For instance, one root user may only be able to execute backup and restore-related commands.

• Process Protection SeOS controls process creation and termination, allowing the security administrator to dictate who make start or stop each process, when they may do so, where the user must be (on the console for instance).

• File Access The rule based ACLs provide great flexibility in determining who can access each file and what may be done to it. Wildcards in the rules provide an easy means to group files together for similar access (for instance, all executables in /bin and /opt/local/bin).

• UID and GID Tracking SeOS logs all UID and GID changes, no matter how they occur, so an accurate audit trail is maintained. The user's original UID and GID always govern the user's permissions.

• Network Protection Once again, SeOS uses ACLs to manage network connectivity. This facility manages which hosts, groups of hosts, or subnets are allowed to connect to the machine, and which services they are allowed to use.

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
I have three important bugs to share this month:

1. A new program called monkey is to S/Key as crack is to standard Unix passwords. That is, monkey takes as input a sniffer log or an skeykeys file 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. monkey was reported on the best-of-security mailing list. (Send subscription requests to best-of-security-request@suburbia.net, or for a digest form to best-of-security-d-request@suburbia.net.

2. Those dang CGI scripts...
   

   The second is a security problem associated with Web sites and CGI-scripts. It is vital and CGI-script interpreters (for instance, the 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.

3. ...and those dang PCs
   

   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 bookstore
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:

• Respondents confirmed that their information systems are under siege. Of those responding, 42 percent reported some form of intrusion or other unauthorized use of computer systems within the last 12 months. More than 50 percent of those who experienced intrusions, or attempted probes of their internal systems, traced those intrusions to employees.

• Altering data in an unauthorized manner (known in the trade as "data diddling") was the most frequent form of attack reported against medical and financial institutions.

• Attacks from U.S.-owned business competitors are relatively common.

• The most significant concern of respondents in regard to eavesdropping, system penetration and attacks in which intruders forge a return address to gain access (known as spoofing) centered on independent hackers and external "information brokers" as likely sources.

• Companies also don't have many of the recommended security precautions in place. More than 50 percent don't have a written policy on how to deal with network intrusions, more than 60 percent don't have a policy for preserving evidence for criminal or civil proceedings, more than 70 percent don't have a "Warning" banner stating that computing activities may be monitored, and more than 20 percent of respondents don't even know if they've been attacked.

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:

1. What the exploit vulnerability is?
2. How to fix the vulnerability?
3. Other references for more information, ie CERT advisories, CIAC, etc.

This database has just begun and does not contain complete information about all vulnerabilities.

If you see a mistake or a suggestion, please email webmaster@iss.net.

Keeping up with CERT

CERT has released a new activity summary. 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?

The Mailbox
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 smrsh, and says

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 75 part 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.

Resources

• Memco Software
  http://www.memco.com/
• best-of-security-request@suburbia.net mailto:best-of-security-request@suburbia.net
  
• best-of-security-d-request@suburbia.net mailto:best-of-security-d-request@suburbia.net
  
• CERT activity summary
  ftp://info.cert.org/pub/cert_summaries/
• CGI-bin CERT advisory
  ftp://info.cert.org/pub/cert_advisories/CA-96.11.interpreters_in_cgi_bin_dir pcnfsd CERT advisory ftp://info.cert.org/pub/cert_advisories/CA-96.08.pcnfsd
• The 1996 Computer Crime and Security Survey
  http://www.gocsi.com/csi/iss_t.htm
• Internet security vulnerability database
  http://www.iss.net/vd/vd.html
• webmaster@iss.net mailto:webmaster@iss.net
  

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 peter.galvin@sunworld.com.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-07-1996/swol-07-security.html
Last modified: