Date: Sat, 11 Nov 2006 16:37:46 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Diego Giagio <dgiagio@gmail.com> Cc: trustedbsd-audit@freebsd.org Subject: Re: I would like to help Message-ID: <20061111161120.T11522@fledge.watson.org> In-Reply-To: <1b0798830611110808g747e91b1xf1912b9b1193cd2b@mail.gmail.com> References: <1b0798830611031732k682b85bey4ea6f769e9692a01@mail.gmail.com> <20061111092821.I63959@fledge.watson.org> <1b0798830611110808g747e91b1xf1912b9b1193cd2b@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 11 Nov 2006, Diego Giagio wrote: > On 11/11/06, Robert Watson <rwatson@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061111161120.T11522>