FreeBSD 6.2 nears release

Robert Watson on the new security event auditing system

Some files and data are managed directly by the kernel because root should not be able to access them. How much can we trust the kernel? We have already seen some attacks that let you gain kernel level access...

Robert Watson: The question of implementing system integrity, and hence log integrity, is a challenging one. Classically, UNIX systems have three security layers: the kernel environment, which has complete control over system hardware and runs in a privileged execution mode, processes owned by the root user, which are typically denied most direct hardware access, but are able to access all facilities through system calls, and user processes, which are constrained to a subset of those facilities and by inter-user protections such as file permissions.

Components required to provide system security are referred to as the Trusted Code Base (TCB), and audit is largely about logging interactions between untrusted users and the trusted code base. In classic UNIX, both the kernel and root user are central to the TCB, as the kernel deals with implementing most access control, but the notions of user authentication and rights assignment occur entirely in user space as the root user.

When audit is added to this sort of system, the kernel and root user typically have the right to modify and view the audit log, but normal users can neither submit records nor view them. The kernel manages the audit trail for two reasons: because it's a primary source of events (system calls), and because it is in a position to make guarantees about log reliability that user processes cannot easily make. In FreeBSD 6.2, we basically follow this model, wherein the root user is able to configure and manage the trail, although there is an audit review group, so users can be added to that group to review logs without root privilege, but the basic model remains the same.

In systems with more complex security models, such as the Biba integrity model present in TrustedBSD and other systems, the notion of the TCB is significantly refined. Operating as the root user doesn't necessarily imply write access to the audit trail - for example, when combining integrity models with the audit trail mechanism, the audit trail is typically considered "high integrity", and can only be directly manipulated by subjects authorised to modify high integrity objects. Trail entries can be appended by lower integrity subjects, but existing records cannot be changed.

Audit support does not, and is not intended to eliminate, these structural concerns. Audit records are, in the end, data, and data has to be protected using the protection mechanisms you have at hand. If the security model has an all-powerful root user, then a root compromise can lead to modified or deleted local logs. This doesn't mean that audit isn't still useful.

For example, audit logs can be piped to a remote machine, meaning that audit logs will capture the behaviour of the attacker, including the initial compromise, up until the point where the audit system is disabled or becomes untrustworthy. It's also important to remember that many attacks don't actually involve root compromise: when performing post-mortem analysis of an insider attack, a web server compromise, or sniffed/grabbed/brute-forced passwords, root access is neither the goal nor required by the attacker.

Is there any support for automatically crypting logs?

Robert Watson:Currently there is no explicit support for this. When logs are cycled, we support running a configurable script, however, and this can be used for encryption, moving trail files around the network, archiving to CD or other write-once media, compression, etc. We don't currently support this as a continuous action on a live stream, although it's something under discussion.

Does the framework provide a secure way to forward logs?

Robert Watson: Currently, no. As with encryption, it's possibly to set up scripted handling of completed trail files, but we don't include native network support. Security distributed audit trail distribution and management is high on the todo list for a future OpenBSM release.

Another thing high on our to do list is support for multiple parallel trails with different security properties on a single system. Right now we have the notion of a single "system" audit trail, although applications can use the BSM library to construct records and write them to either the system trail or to a file they maintain themselves. We'd like to add support for the system to host multiple concurrent trails, perhaps associated with specific applications, jails, and so on, which operate independently and can be accessed using different privilege sets.

For those interested in trying out experimental Audit support in FreeBSD 6.2, an excellent starting point is the FreeBSD Handbook chapter on configuring and adminstering audit support. There are also fairly extensive man pages covering both administration and the programming environment.

Programmers of IDS systems may be particularly interested in the auditpipe(4) facility, which allows applications to tap the live event stream, specify filters on what audit records are delivered to the application, etc. This is a great tool and allows IDS systems to directly control record gathering without interfering with the system trail or other monitoring applications that have different record requirements.

This article originally appeared in Security Focus.

Copyright © 2006, SecurityFocus