Original URL: https://www.theregister.com/2006/11/13/freebsd_security_event_auditing/
FreeBSD 6.2 nears release
Robert Watson on the new security event auditing system
Posted in Software, 13th November 2006 11:38 GMT
Interview The upcoming release of FreeBSD 6.2 includes the new security event auditing system, that "permits the selective and fine-grained logging of security-relevant system events for the purposes of post-mortem analysis, intrusion detection, and run-time monitoring analysis".
Federico Biancuzzi interviewed TrustedBSD project founder Robert Watson, and discussed the advantages and potentialities it brings.
Editor's note: as of this writing, FreeBSD 6.2 is in beta3 status with the final release expected very soon.
Could you introduce yourself?
Robert Watson: I first touched a BSD box in around 1994, thanks to the donation of a BSD/OS system and SLIP connection from UUNet to my high school. It was love at first sight! Discovering FreeBSD not long after, I've been a regular FreeBSD user since around 1995, although I only became involved in FreeBSD development in 1999, gaining a "commit bit" to help maintain the FreeBSD portions of the Coda distributed file system, a project I had worked on while at Carnegie Mellon university.
My undergraduate degree is in Logic and Computation, from CMU's philosophy department, along with a double major in Computer Science, but it became clear that my greatest interest lay in operating systems and security.
After working on file system ACLs and mandatory access control for FreeBSD, I started the TrustedBSD Project in 2000, with the goal of bringing more advanced security features to the platform.
In 2001, while working at Network Associates Laboratories (NAI Labs, and later McAfee Research), I proposed and became principal investigator on a research project as part of DARPA's CHATS research program, which was investigating security and open source. This project included sponsoring and developing UFS2, OpenPAM, the TrustedBSD MAC Framework, NSS support, PAE support, several network stack hardening projects (including syncache and syncookies for FreeBSD), GEOM, and GBDE. Since that time, I've lead projects to port the SELinux FLASK/TE module to FreeBSD, implement Audit on Mac OS X and FreeBSD, and to port the TrustedBSD MAC Framework to Mac OS X.
I've also become actively involved in the FreeBSD SMP network stack work, become a FreeBSD Core Team member, a member of the security officer and release engineering teams, and president of the FreeBSD Foundation.
In the autumn of 2004, I left employment at SPARTA, Inc, as a aenior principal scientist to start work on a PhD at the Computer Laboratory at the University of Cambridge, working in the areas of operating systems, windowing systems, and application security. My work on FreeBSD continues as part of my research, intermittently under contract to various FreeBSD-consuming companies, and quite extensively in my spare time.
What is the Security Event Auditing that has recently been included in FreeBSD?
Robert Watson: Security Event Auditing refers to the fine-grained logging of security events in the system, and is basic security functionality long overdue in open source operating systems. There are three things that differentiate auditing from traditional OS logging facilities such as syslog: security/reliability, granularity, and configurability.
Security standards require that audit trails be both secure and reliable - for example, that log records only be accepted from trusted sources, and that they be delivered with reliability guarantees to the audit log. They require the ability to track very fine-grained security events, including files accesses, network events, and so on.
Finally, the standards require that this be configurable so that the rate and content of logging can be usefully managed. UNIX syslog does none of these facilities well, if at all, as it is a general purpose log mechanism.
Our code is derived from the Mac OS X audit implementation created by McAfee Research for Apple's Mac OS X Common Criteria evaluation, which was generously released by Apple under the BSD license. During the work for Apple, we identified Sun's BSM API and file format as the de facto industry standard for UNIX audit implementations - it was extensively documented, the foundation of a previously evaluated system, and was extensible to new events and data types.
As an added bonus, it was already widely supported by intrusion detection and other software systems that consume audit records. Our implementation maintains the flexibility to switch to other formats in the future, but BSM appears to be serving us very well currently.
The Apple implementation consists of three parts: a kernel audit event engine and event sources, a userland library and toolset for managing audit data, and extensions to applications to generate audit logs. We ported the kernel portion to FreeBSD, enhancing it significantly as part of our "audit3" implementation. This included making it endian-independent, extending is coverage of events, and adding facilities to support live intrusion detection, such as audit pipes. These allow applications to attach to the live audit stream and specify interest in types of events to track.
We also enhanced the library and tool suite significantly, making it endian-independent, adding 64-bit support, adding missing APIs, documenting it, and generally cleaning things up. We have released this code as OpenBSM, which is portable to a number of systems, including FreeBSD, Mac OS X, and Linux. This means you can process audit compatible trails from FreeBSD, sparc64-based Solaris and Mac OS X on any of these platforms, and it is a relatively simple task to port to additional platforms. Finally, we re-implemented the application extensions for FreeBSD, such as changes to login(1) and su(8), which differ significantly across operating systems.
We have also spent a lot of time creating documentation, writing a FreeBSD Handbook chapter on configuring audit, man pages, and so on. Users will also find that much of the existing Mac OS X and Solaris audit documentation applies directly to FreeBSD, especially as relates to configuration files.
How does the audit framework work?
Robert Watson: Configuring audit is quite straight forward. We do not ship the GENERIC kernel with AUDIT support enabled, as it will be considered an experimental feature for FreeBSD 6.2, so you will need to recompile the kernel with "options AUDIT". All of the necessary tools are compiled into user space by default, however. To turn on basic audit, add the following line to /etc/rc.conf and reboot:
auditd_enable="YES"
This will enable the audit daemon. The default configuration audits login and logout events, but it can be configured to audit in much greater detail. Configuration files for audit are found in /etc/security. To audit all program execution performed by authenticated users, you can modify the flags line and policy lines in audit_control(5)to read:
dir:/var/audit flags:lo,+ex minfree:20 naflags:lo policy:cnt,argv
After restarting the audit service, successful calls to execve(2) will be included in the audit log, producing a detailed trace of user activity. The praudit(8) tool is used to convert BSM trails to text for analysis, and the auditreduce(8) command can be used to select specific records for processing. For example, the following command line will print the tail end of the current open audit trail:
% praudit /var/audit/20060919152519.not_terminated | tail -14 header,194,10,execve(2),0,Fri Sep 22 11:25:28 2006, + 186 msec exec arg,/usr/sbin/praudit,/var/audit/20060919152519.not_terminated path,/usr/sbin/praudit attribute,755,root,wheel,90,74867,293408 subject,robert,robert,robert,robert,robert,27579,24249,60949,131.111.204.168 return,success,0 trailer,194 header,128,10,execve(2),0,Fri Sep 22 11:25:28 2006, + 189 msec exec arg,tail,-14 path,/usr/bin/tail attribute,555,root,wheel,90,27225,114880 subject,robert,robert,robert,robert,robert,27580,24249,60949,131.111.204.168 return,success,0 trailer,128
One interesting thing about audit is that we log the authenticated user, not just the UNIX real/effective uids. This means that activities performed after su'ing will be traceable both to the original user who logged in, not just the user switched to, which can be quite useful for introducing accountability for shared role accounts. Using auditreduce(8), you can select down to particular users, particular files, times of day, type of operation, and so on.
You can find more information on audit in the FreeBSD Handbook chapter on audit, as well as detailed information on configuration file formats and tools in the man pages.
Audit is required for Common Criteria evaluation. Do you think this feature could help FreeBSD gain more market share in enterprise and government agencies?
Robert Watson: Common Criteria evaluation is critical to the adoption of operating systems by a number of major software consumers, including US DoD and other parts of the US government. Even without evaluation, audit is an important software requirement for many other security-sensitive organisations, such as banks.
Inclusion of this feature in FreeBSD will open a lot of doors. On the other hand, adding audit support is not the same as completing evaluation - evaluation is a very expensive prospect, and typically happens in the context of a vendor with a specific product, not an open source community project.
Our goal has been to facilitate evaluation of FreeBSD by its consumers and resellers, not perform the evaluation itself. FreeBSD should now meet almost all of the technical requirements for a basic CAPP evaluation, if someone should come along wanting to do one. As FreeBSD has been evaluated numerous times under the common criteria as part of various products, such as routers, firewalls, and so on, there's a lot of evidence that such an evaluation could be completed successfully without much additional development work.
What type of advantages could a forensic technician get from it?
Robert Watson: Post-mortem analysis is a tricky business - you want to figure out how the system was broken into and what was done, but this is complicated by the fact that software is extremely flexible and there isn't much log information. It could be that the first thing you know of an attack is a defaced web page, but maybe the actual break-in occurred weeks before. A detailed audit trail of events can often directly answer the question of how and when the break-in occurred, and allow the technician to backtrack through the log identifying what files were modified by the attacker, what software was run, and what other activities, such as attacking other systems, were performed.
As audit is flexible to configure and we ship trail reduction tools, administrators can decide on their own trade-offs between disk space use, performance impact, and log completeness. For example, administrators might choose to audit only system logins, which has very low space and performance overhead - or, they might choose to audit all commands executed and system logins, costing somewhat more in space and overhead, keeping execution information for four weeks, then reducing the logs down to only login information and keeping that for 12 months.
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