| Previous | Table of Contents | Next |
Audit consolidation is performed by the emitter daemon running on each node and the collector daemon on the audit server. Both daemons support configuration files in which the output format, filters, and log file characteristics can be defined. Audit records include a sufficient amount of information, roughly equivalent to what is found in audit records from the base operating system. APIs are provided for accessing the audit records in binary form. The events reported in normal auditing of SeOS are primarily access control events or login events.
How does SeOS decide what to audit? When users or resources are defined, the security administrator sets the audit characteristics for those entities. Again, the events for users might be successful or unsuccessful logins. For resources such as files, events include access successes or failures. Individual file auditing is thus supported. Resource access can be set to notify so that each time someone accesses a particular file, for example, e-mail can be sent to a set of addresses. At this time, the response capability does not seem to be configurable, although custom responses are possible in the TME Event Console when SeOS is used as part of Tivoli’s Security Manager product.
Audit logs can be scanned or reported on using CLI or the interactive GUI. A separate audit server is not required. The audit logs can be examined on each system. Filters include the following:
Filters for viewing audit records can be wildcards or specific entries. Indeed, for many of the fields in a given access control constraint, wildcards are accepted. Possibilities include “Joe can access file /home/foo only when requested through program /bin/v*.”
The Trace log is similar to the audit log and can be configured to store its output in the audit log. Trace logs include more detailed information including process create, fork, exec, process death, setuid() calls, setgid() calls, and more as the documentation claims. Many of the Trace events are SeOS related. These events include administrator activities such as “user XYZ ran the seadmin command with these parameters…” The entire set of Trace messages provided is contained in roughly 25 pages of documentation in a SeOS publication appendix.
SeOS protects against su, SUID, and SGID escalation with access control rules. Individual SUID programs can be limited with the types of variables described in this chapter (user, group, time of day, and so on). SeOS will scan the system for SUID programs, for example, or you can enter names individually. This additional level of access security addresses some of the concerns regarding SUID and SGID programs. An administrator can specify some very complex predicates that are used to limit normal user access to privileged programs. Because hackers often look for privileged programs to exploit, this feature is valuable. One simple approach is to disallow running of privileged programs from users that login remotely. This approach actually requires some fine tuning, because programs such as e-mail fall into this category.
Many customers complain about UNIX because it permits the same user to log in more than once simultaneously to the same system. Others see this feature as an advantage. In any event, like mainframes, SeOS can limit individual users to a single active login session per node.
SeOS can be configured to disable logins based on failed login attempts. Flexibility exists in how this can be done. For example, N failed logins from a given source would block logins only from that source IP address, terminal, or X-station. Although most operating systems support login disabling after a configured number of failures, blocking from a specific source is designed to reduce the denial of service threats due to login failures. (Remember this from Chapter 2?)
The Tivoli Management Environment (TME) layers a uniform security model on heterogeneous operating systems. Like the individual privileges or rights that a user on NT can be assigned, the TME security model supports granular privileges using a role-based model. Role-based access control is both a practical and a research topic, meaning that you can find both commercial products and formal papers about the area. Essentially, a role is a collection of operations or privileges. A user can belong to one or more roles. When an operation is initiated by the user, various access rights are verified based on the roles assumed by the user.
A role-based architecture, such as the one provided by TME, is flexible enough to permit arbitrary definitions of roles beyond the predefined set in NT, for example. Roles can be defined for the operating system as well as for application-level programs. Depending on the situation, a program may need to be modified to be aware of the role-based model, or the model can be layered over an existing environment including much of the UNIX operating system. Unfortunately, when layered over UNIX, the root access problem still persists. That is, you or a hacker can always bypass the processes on the system implementing the layered approach and work directly with system programs or processes. Still, role-based architectures provide promise for access granularity for systems management and application programs beyond what is delivered in off-the-shelf operating systems today.
One of the main points to remember from this chapter is that the success of access control depends heavily upon knowing the subject of the request. Who the system thinks you are is controlled at login time by I&A processes detailed in the preceding chapter. In this chapter, you also saw how you could change who you are in the system through privilege escalation in UNIX and impersonation in NT. As part of the normal activities on a system, various programs increase and decrease their privileges on a regular basis. This basic behavior is one of the most often exploited characteristics of systems. Hackers look for weaknesses in privileged programs to gain superuser access to a system.
| Previous | Table of Contents | Next |