I would like to help

[Robert Watson]

On Sat, 11 Nov 2006, Diego Giagio wrote:

> On 11/11/06, Robert Watson <rwatson at freebsd.org> wrote:
>> Thanks for your e-mail!  Your help would be most welcome.  There is quite a 
>> bit of work to be done; right now we're not maintaining a unified TODO list 
>> for the FreeBSD audit implementation, rather, there are a few lists 
>> scattered in various places.  You can find a short TODO list in the OpenBSM 
>> distribution (some of the items in the most recent release have now been 
>> done, FYI, so check first).  The distributed audit daemon is one of the 
>> more interesting outstanding areas to work in, but there are others that 
>> probably ought to go into a TODO list somewhere.  In my recent presentation 
>> at the FreeBSD developer summit, I identified the following areas in which 
>> interesting new work can and should be done:
>> 
>> -Finish syscall assignments, especially for ABIs
>> 
>> - Flesh out argument auditing
>> - Audit + NSS
>> - Userland sweep
>> - Ports + packages
>> - Language bindings
>> - Enhance audit pipe preselection
>> - Multiple audit pipelines
>> 
>> - IDS/monitoring tools - Distributed audit
> - New parsing API
>
> Let the work begin! I'll be sending specific e-mails to the list to collect 
> information and begin contributing. Thanks.

Heh.  I actually intended to postpone that e-mail and flesh out each of the 
ideas some before sending.  Sorry about that!  I'll try again here rather than 
sending you on an excessive wild goose chase:

- Finish syscall assignments, especially for ABIs

For the native FreeBSD ABIs, we've assigned audit events to almost all system 
calls (see src/sys/kern/syscalls.master, 
src/sys/compat/freebsd32/syscalls.master).  However, there are still some 
system calls that need events assigned, and certainly reviewed in detail.  In 
addition, there are a number of system call tables, such as the Linux 
emulation tables, which need both assignment and review work.

- Audit + NSS

Right now, libbsm implements the /etc/security databases purely based on 
files; it may well be desirable to support distributing them using NIS, LDAP, 
etc, along with the accout database (especially audit_user), in which case it 
will need NSS support.

- Userland sweep

A moderate number of the interesting audit events come from user space -- 
especially, authentication, user login access control, login/logout, user 
administration, etc.  We've updated some tools (login(1), su(1), sshd(8)) to 
generate audit records using various APIs, but quite a number still remain.  A 
sweep to identify these programs, as well as addition of audit record 
generation, is required, and needs to be done in the context of CAPP.  One 
that needs early attention is ftpd.

- Ports + packages

There are some important ports/packages that need adaptation; some already 
have BSM support (OpenSSH, for example), but others need modifications.  The 
most critical ones are things like xdm/gdm/kdm/lukemftpd/etc.

- Language bindings

Right now we provide a C API (that can, I believe, be used with C++).  There 
are existing Java classes for BSM; there might also be perl.  A possible 
project might be to work with various language developers to create classes 
(etc) to support BSM.

- Enhance audit pipe preselection

Applications can open /dev/auditpipe to create and open a new audit pipe 
instance, teeing the live audit stream.  By default, you get records destined 
for the trail.  We also support putting the audit pipe into a "local" mode, in 
which the preselection properties of the pipe can be changed locally to the 
pipe, operating independently from the trail and any other pipes in use. 
This works quite well; however, the preselection model is simply a mirror of 
the model used for the global trail, consisting of global flags, naflags, and 
optional per-auid masks.  It could well be that another model would be more 
useful for real-world monitoring and IDS applications.  In the context of 
these applications (i.e., real-world experience) it might be a useful activity 
to explore adding alternative models to preselect records for a pipe.

- Multiple audit pipelines

Traditional OS audit has largely been intended to audit system security events 
-- login, file system accesses, password changes, etc.  However, there are 
many situations in which you may also want to generate audit trails from 
critical applications, such as databases, web servers, etc.  It seems 
desirable that we be able to handle these event pipelines independently, since 
they have quite different security properties.  This suggests allowing more 
than one "audit pipeline" to exist, each with its own security and reliability 
characteristics, trail destination, etc.  This is a complex thing to do, and 
the requirements are a bit unclear, but I think that there are some quite 
interesting things that can be done.

- IDS/monitoring tools

The audit trail and audit pipes allow access to very fine-grained security 
information -- while historically this was intended for post-mortem "after the 
fact" analysis, the obvious things to do are IDS and system monitoring. 
There are several commercial and research IDS systems out there that can 
already consume audit trail data, often even BSM data on Solaris, and many can 
be adapted to run in FreeBSD.  There's also lots of room to write new IDS and 
monitoring tools, especially given the flexibility of the audit pipe model.

- Distributed audit

This is a slightly vague concept, but I think really comes down to two things:

(1) distributed monitoring and management of audit on multiple machines,

and

(2) [secure, reliable] transmission of audit trails across multiple machines

The details and requirements require quite a bit of thinking, but obvious 
issues to look at would be cryptographic transport, reliable sequencing and 
spooling of trail segments, etc.

- New parsing API

One of the problems we've run into with BSM parsing is that it's difficult to 
process BSM without significant context: the most basic example of this is 
that trails exist in both big- and little-endian formats on some platforms 
(Solaris), and you need that information to properly parse records and tokens. 
Likewise, at a higher level, it's helpful to keep track of the OS, BSM 
version, source machine, security context, etc, in use when it comes to 
interpreting records.  There are also issues in how to manage the I/O model, 
integrate with sockets, etc.  The solution is probably a new parsing API that 
is stateful.  Exploring this to see what the requirements are (etc) could well 
make an interesting project.

Hopefully this provides a bit more insight. :-)

Robert N M Watson
Computer Laboratory
University of Cambridge