Date: Mon, 5 Apr 1999 13:56:41 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: freebsd-security@freebsd.org Subject: POSIX.1E auditing support, an initial pass and some questions Message-ID: <Pine.BSF.3.96.990331224610.4650D-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
Over the past month, I have been working on a first pass at implementing system auditing for FreeBSD 4.0-CURRENT based on the POSIX.1E spec. I have an initial alpha version working at this point, and had some questions about appropriate ways to hook the behavior into the kernel efficiently and effectively. The URL for the existing code is http://www.watson.org/fbsd-hardening/posix1e/ The essential scheme goes a little like this: POSIX.1E supports a flexible "audit record" designed to describe a single event, be it a kernel event or an application-submitted event. The draft defines a number of accessor routines to retrieve, manipulate, store, and submit these records from userland. The large majority of the existing code implements this API, which is described in a fair degree of depth in the man pages included with the tarball. The kernel implementation currently makes use of an audit device (/dev/audit) to ship audit records from the kernel to a userland auditd, a daemon listening on the device, somewhat similar to syslogd and /dev/log. Auditd would be an excellent place to put filtering capabilities, and also IDS types of code. I'm currently working on a modular IDS plugin API for auditd so that modules capable of detecting various types of attacks or unusual behavior could hook into the record stream, and raise standard warnings, etc. This modular behavior is not included with the daemon; right now it just logs the audit records after doing a little filtering. My real questions have to do with the best way to hook syscalls: the audit format, for most syscalls, requires the logging of relevant arguments, information about the acting process (and optionally objects acted upon), and the return code (or error, and what kind of error it was security-wise). All records have some standard information, and some event-specific information. The results are fairly ugly and complicated kernel hooks, so far. First off, many times arguments are not copied into the kernel by the syscall itself, rather by a uio call as part of a vnode lookup; similarly, syscalls may exit in a number of places for a number of reasons, resulting in a lot of hook locations for the record. Right now I have hooked a few syscalls (no where near any significant number :-) as a proof-of-concept exploration of what might be involved, and am soliciting suggestions about a clean way to handle this. The code is under a 2-clause BSD-style license, and leaving aside the kernel code, should be portable to other platforms. Because this is extremely test-ish code, it's not something that anyone would want to run regularly except in a development sense. Also, without record filtering in place, even the few syscalls that are hooked generate a lot of output. However, feel free to download it, run it, etc. Because it adds new syscalls, it does require that you rebuild libc, so is probably not for the uninitiated. Please feel free to send questions to me directly or on this list; questions about the POSIX.1E spec should be addressed to the cross-platform POSIX.1E discussion list (posix1e@cyrus.watson.org). Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990331224610.4650D-100000>