some questions about audit

[Robert Watson]

On Wed, 12 Oct 2005, panxj wrote:

> 	I have downloaded trustedbsd_audit3 through perforce, and wanna to 
> add some further enhancement to it. I'm reading the soure code, but now 
> have some questions:
>
> (1)There are over 1000 system-calls in current system(including the 
> bianry-compatible system-calls, such as functions listed in 
> linux_sysent). But arguments-collection points are only added in about 
> 28 funcitons. Is it sufficient? And is there any documents about why 
> these collection points are added?

The answer varies a bit by system call and system component, but the 
status goes something like this:

While there are many ABI's available that implement literally thousands of 
system calls, the vast majority of those system calls are identical to a 
relatively small set of base calls.  For example, while there are minor 
syntactic differences between sendfile() in the 32-bit system call ABI for 
FreeBSD and the 64-bit one, they are basically the same system call.  As 
such, they will be audited as the same event, AUE_SENDFILE.  Likewise, you 
will find literally dozens of various on stat() across Linux emulation, 
this emulation, old versions of stat() with smaller sizes, etc.  These 
will all be emulated as AUE_STAT.

What's particularly helpful is that not only are the events basically 
identical, but they are also implemented by the same code in most cases: 
the emulation layer is simply a wrapper that converts, say, native Linux 
layout for a structure into the FreeBSD version of the structure, and then 
converts in the reverse direction on return.

For example, linux_fstat64() is implemented as a small wrapper around 
kern_fstat(), which is the internal kernel implementation of the fstat() 
system call.  This means that augument auditing in that one spot, 
kern_fstat(), will capture the necessary information about all fstat() 
variations.  This does discard some potentially interesting information: 
that the call was made via the Linux ABI; however, it was concluded that 
the improved cleanliness and centralization of the audit implementation 
outweighed the benefit of providing this additional information.  It may 
make sense to add an additional token to the AUE_EXECVE audit record to 
capture what ABI is used for the binary, however.

Likewise, path information is uniformly collected in namei(), with the 
caller indicating which string is to be audited (the first or second).

There are a few system calls in emulation layers, such as Linux's getcwd() 
system call, and library mapping functions, that will need additional 
work.

> (2)What's the status of the audit-subsystem? If it has been done for 
> 90%, or 30%? When it will be added to the release? Thanks to all in 
> advance.

However, it is still the case that a number of arguments are inadequately 
audited.  We are constructing a table of system calls and arguments in the 
audit3 tree, under the notes sub-directory.  It's currently not very 
complete, but we're working on fleshing it out.  Recent work (in the past 
few weeks) has focused on cleaning up the event framework itself, and 
doing some necessary restructuring.  We've also been adapting to recent 
changes to an MPSAFE VFS in the base FreeBSD tree (now done), and been 
adding BSM event identifiers for system calls present in FreeBSD and 
emulated platforms that are not present in Solaris (such as sendfile()).

Originally the plan was to integrate the audit support, including the 
OpenBSM libraries and components, into FreeBSD for the 6.0 release. 
However, as we're waiting on Apple to re-release a couple of the audit 
source files under the BSD license instead of APSL, that was deferred. 
The original hope was that the relicensing would be done in June, which 
obviously hasn't happened.  It is apparently moving through Apple Legal 
and we hope for progress soon.  As such, my current target is FreeBSD 6.1 
as an experimental feature. We'll begin merging parts to 7.x as soon as 
the license is fixed.

In terms of overall completeness -- Wayne Salamon and I have been starting 
to assemble a todo list on what remains, which can be found in Perforce:

    //depot/projects/trustedbsd/audit3/notes/TODO_audit.txt

This is also in the cvsup export.  In particular, we need to complete a 
sweep of all system calls and arguments to make sure they are audited. 
In the case of new record types we've added for BSD system calls, we need 
to more formally define the structure of the record in terms of expected 
tokens.  We also need to take a sweep through user space, which currently 
has not had a lot of attention paid to it, and requires that attention. 
Another task of importance is integrating the audit mechanism with the MAC 
Framework so that MAC security policies can annotate audit records.  Wayne 
has a first cut of this as part of work he has done for SPARTA, and some 
of which is now available via the DSEP Darwin tree from our port to 
Apple's Darwin platform.  Finally, a lot of testing, and expecially 
testing tools, is required.

If you'd like to lend a hand with any of these things, especially 
unclaimed items in the todo list, would be great.  One of the things that 
doesn't have an owner and would make a good chunk to work on is teaching 
our praudit implementation how to convert binary BSM log files into the 
XML output format Sun has now defined, as this may be more appropriate for 
analysis by higher level applications.  This should also help expose 
things missing in our audit trail. :-)

Thanks,

Robert N M Watson
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message