The commonly used terms in SeOS are subject (or accessor) and resource. Access control features include the following:

•  Login limits varying time of day, day of week, source network address, or physical terminal.

•  Limits on which programs can be killed, even by root.

•  TCP/IP packet filtering by services, host, host-groups, network address, hostname patterns, or port number (firewall-like services).

•  TCP/IP access control by user or group combined with the preceding variables, including inbound and outbound connections where applicable. (Joe cannot telnet out; Joe cannot accept a connection.)

•  For almost every access control constraint, one can specify time of day, day of week, and controlling terminal. (Joe can run /bin/vi but only on Wednesday from 9–11 and when logged in from IP address 1.2.3.4.)

•  Trusted computing base (Tripwire type) protection for SUID/SGID programs that the administrator defines; if the TCB signature changes, the program is no longer trusted and cannot be run until retrusted by the SeOS administrator.

•  Division of privileges so that root cannot tamper with auditing or audit files.

•  Watchdog daemon that ensures SeOS daemons are running.

•  Program pathing that limits access to a resource only when the user is doing so from a particular program name. (Joe can change /etc/hosts but only when done through the /bin/trustme editor.)

•  Password quality rules.

•  SUDO for root privilege granularity, giving unprivileged users the ability to run a subset of administrative commands (start/stop printers or user management, for example).

•  Locking of idle terminals or X-stations after N-minutes of inactivity.

•  Full CLI or GUI.

•  Resource protection, such as files and directories, even from the root user.

APIs

Program APIs are provided for nearly all of the functions SeOS contains. An arbitrary resource can be defined; access control rules for this resource can be declared; and access requests can be queried by the resource controller using these APIs. Note that this is very much like DCE in that it represents a general-purpose access control framework and is not limited to UNIX semantics like “file on a disk.” In other words, a resource’s controlling program may view different parts of a normal UNIX file as different access control regions, and SeOS can be used to regulate which users (or other accessors) are permitted to access various regions of the file independent of its UNIX permission bits. The resource has a dual identity: (1) as a file with UNIX permission bits and SeOS access control constraints and (2) as a resource whose contents are subdivided into SeOS access control regions that are only meaningful to the program subsystem which owns the file. This idea is very powerful because access control can be applied to concepts that are more granular than traditional UNIX or NT resources.

Impact of SeOS on Base Operating System Security

Because the system call that SeOS intercepts is eventually executed when access control is permitted, the base operating system’s auditing features are generally unaffected by SeOS. One exception to this occurs with root privilege division.

Most UNIX systems do not support a standard mechanism for dividing root privileges among multiple users. SeOS includes a program that executes as a root process but performs tasks on behalf of unprivileged users. The SeOS database is configured to control which users are permitted to run special privileged programs. Here, a privileged program means one that is usually not accessible by the ordinary user because it is in a protected directory or because its permission bits do not allow access. This definition does not necessarily include SUID or SGID programs that are addressed separately by SeOS.

Privilege granularity, in which ordinary users can be given limited root privileges, is an exception to base system auditing in that the audit record shows UIDs (real, effective, and audit) that represent root rather than the login user. The UIDs belong to root because SeOS is executing a process on behalf of a requesting user. In other words, this new function is not normally available in UNIX systems. For a monitoring system to assign accountability for a behavior that occurred during privilege delegation, the monitor would need to look at SeOS audit logs as well as the operating system logs.

IDSs are affected in other ways by SeOS and other software products that intercept system calls. You’ll learn more about this concept as you dig into intrusion detection in Part 2, “Intrusion Detection: Beyond Traditional Security,” of this book.

SeOS Auditing

SeOS emits its own audit trail for security tracking. Even without a security policy, SeOS reports on important activities, such as login, logout, password changes, fork, exec, and so on. The types of events reported include the following:

•  Access control success and failures

•  Additions, deletions, and changes for the SeOS database

•  Individual commands run at the SeOS console window (that exists on each managed node)

•  Logins (failures and successes)

•  System startup and shutdown

•  Audit startup and shutdown

Like the base operating system audit services, an audit ID (AUID) is added to each audit record.

Audit records are logged in either binary or text form based on the configuration. Logs can be consolidated to a central audit server based on scheduled parameters. The audit server consolidates the distributed audit logs into a single file by adding the hostname to the beginning of each record. This consolidation enables the user to be able to filter based on hostname at the audit server. On each audited node, one can configure audit filters that determine the types of audit events forwarded to the audit server. This feature can help reduce bandwidth on the network and reporting time at the audit server because unimportant records are not forwarded.