Previous | Table of Contents | Next |
The commonly used terms in SeOS are subject (or accessor) and resource. Access control features include the following:
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 resources 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.
Because the system call that SeOS intercepts is eventually executed when access control is permitted, the base operating systems 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. Youll learn more about this concept as you dig into intrusion detection in Part 2, Intrusion Detection: Beyond Traditional Security, of this book.
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:
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.
Previous | Table of Contents | Next |