| Previous | Table of Contents | Next |
A couple of solutions to the first problem exist. You can diligently try to analyze every possible access permission for objects in your environment and hope that you set them properly. In practice, this approach has not been completely successful, which is one reason the marketplace is so interested in intrusion detection for finding leftover weaknesses. Because your site also contains many custom or purchased applications, properly configuring the NT or UNIX operating system settings alone will not secure your site. For example, if you run a Web server on your system with exploitable bugs, and the operating system is locked down tightly, hackers will still be able to penetrate your defenses. Unfortunately, only time will tell whether your configurations are adequate. The other approach, monitoring your systems, is the only way to know for sure that your access control policies are defined correctly or have been modified without your knowledge. Intrusion detection products are expressly designed for this purpose. Among other things, they look for evidence indicating that a user has created a SUID root program, accessed a normally unavailable directory, or altered resources belonging to another user.
System monitoring also can help solve the second problem. By watching privilege increases for users, you can be alerted when a security policy violation occurs. Already mentioned are two famous techniques for gaining additional privileges—the GetAdmin hack on NT and the buffer overflow attack (Aleph One, 1997) now so common in UNIX. (The Phrack article written by Aleph One contains material originally posted by Mudge at the L0pht Web site www.l0pht.com). Other flaws in privileged programs have been exploited by users to gain additional privileges.
Only by monitoring your systems will you know that your security policy is being enforced properly. Intrusion detection can solve security problems that I&A, access control, and even firewalls do not. Before launching further into these discussions, though, you can improve access control on out-of-the-box UNIX and NT systems by installing other products. Several access control security products are available to sit on top of UNIX and NT operating systems. Many of these products merely provide a thin veneer over the existing features in UNIX and NT.
One particular product, Memco’s SeOS, adds significant value. Portions of SeOS have been incorporated into Tivoli’s Security Manager product. What is SeOS?
Monitoring and intrusion detection products work by identifying who performed what action. The who is determined from the AUID of a process or by deducing the AUID from a series of events. One of the problems with the UNIX operating system is that access control decisions are made most of the time by using the EUID or EGID. In some cases, the RUID and RGID might be the basis for the decision. SeOS limits access based on the AUID and provides stronger protection. IDSs use the AUID to assign accountability because it is a reliable indicator of who is performing the action. SeOS uses the AUID to regulate access control for the same reason.
SeOS also provides for the capability to limit accesses based on the path of access. For example, SeOS can limit access to a resource depending on the program that a user is running to get to the resource. These two features are among the best advantages of SeOS.
SeOS is a real-time access control product that intercepts a subset of system calls, performs a user exit routine, and then either rejects the access request or passes control to the kernel for processing. In the user exit, SeOS compares the parameters of the request (UID, GID, file name, or resource name) to its database of access control constraints. If no constraint is violated, the user exit completes with success and the request is forwarded to the requested system call. SeOS does not replace any system calls.
Each SeOS enabled node has a local database. Several daemon processes are run on the node as well. The database can be updated from a remote system if configured to accept inbound commands. The managed nodes may subscribe to a central policy manager to obtain database updates. The SeOS environment is managed by a SeOS administrator and a SeOS auditor. Both of these users are distinct from the root user.
Managed resources can be assigned labels and categories that are used to enforce mandatory access control (MAC). This feature is also applicable to network resources such as hosts or services. No capabilities are provided for MAC on System V IPC semaphores, message queues, or shared memory. Communications between distributed systems are accomplished via DES encryption between nodes. The entire encryption library can be replaced and example code is provided. For example, if someone wanted to substitute weak encryption for export, SeOS supports extensions. No key distribution framework is provided for ensuring that all communicating parties share the same secret.
Access Control Constraints
To summarize SeOS in one sentence, it is best described as RACF mainframe security on UNIX. SeOS terminology comes from both UNIX and RACF, but SeOS is sometimes summarized as an attempt to provide traditional mainframe administrators with familiar concepts for specifying a security access control policy when working with UNIX and NT systems.
Many systems are configured to allow root access only from a physically attached terminal. The only way to gain root privileges remotely is by using the su command to switch from a normal user to the root user. The AUID is not changed by the su command. That is, the su command does not hide who the user really is. SeOS uses the AUID to make access control decisions and is not fooled by su transitions. Even if a hacker guesses the root password and can su to root, access to a resource will not be granted if SeOS is configured properly. This feature goes way beyond the access control security features supplied in UNIX and NT by default. In a typical UNIX configuration without SeOS, the su operation would give the remote user full access to the system.
| Previous | Table of Contents | Next |