Date: Mon, 12 Apr 1999 09:39:31 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: freebsd-security@FreeBSD.ORG Subject: Re: POSIX.1E auditing support, an initial pass and some questions Message-ID: <Pine.BSF.3.96.990412092814.11402E-100000@fledge.watson.org> In-Reply-To: <386.923562532@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 8 Apr 1999, Poul-Henning Kamp wrote: > It sounds to me like you will be overlapping with KTRACE to a great > extent, have you considered unification of the two ? Certainly your > stuff can do anything that KTRACE can, so if anything we should > be able to get rid of KTRACE if we adopt your stuff. There is also > some overlap with process-accounting come to think of it. I thought about this briefly, and later received email from Nate on the same topic. I agree that, if possible, we should have one mechanism for generating traces, optionally formatted as audit records. The audit mechanism doesn't trace things like signals or care about a number of other events. My temptation would be to go for an modified KTRACE as it's already in place and (presumably) moderately efficient, and then have a funneling module that converts the KTRACE data into an audit record format, or more extensive process trace format. The auditing data defined by POSIX.1e is limited to user-requests that the POSIX folk considered the be relevant--i.e., brk()/sbrk() aren't there, but open() is. They allow for local extension as needed, but holding to their philosophy is probably useful. Also, defining a set which is useful for other camps (*BSD, linux, etc) is probably a good idea so portability can be maximized. > There is no easy way to get all args to all syscalls, they're too > unsystematic for that. I had suspected (and observed) as much. What is the rational behind having the name lookup pull the pathname into the kernel as opposed to using a copyin in the syscall and passing it in as an argument? Presumably someone, somewhere has to allocate space on the stack, and if it's done in the syscall function then more argument processing is done in one place? This would make at least a bit more available to an auditing layer in the syscall. > Have you considered to do (some of) the filtering in the kernel > in a manner like bpf ? This would reduce the performance impact. Yes. Once the kernel interface issue was sorted out, I had plans for at least a rudimentary mask functionality, although having something stronger (ie, bpf) would certainly be better. The mask I had in mind was something on the order of a set of processes interesting an audit record customer, and then a mask of event types (mappable fairly directly to syscalls, etc). Right now I have it configured so there is only one consumer sitting on a queue attached to /dev/audit. My intent there was to have auditd process as necessary, and then provide records to other consumers by way of IPC or dynamic linking of IDS modules into auditd and a standard access API. > I would also love to have a remote audit ability where the audit > records are never passed into userland on the audited machine, > but instead shipped over a network (or other interface) to a > monitor box. That would certainly be possible, and would definitely be useful :-). I didn't have plans for this in the pipeline, but that could be a great feature. Of course, the pipeline trails off a little at this point because of the "intergrate into the kernel" issue :-). Presumably one could optionally also throw in the use of a one-way hash for speedy authentication by shared secret. I would think putting public key support in would belong in a user-land daemon until the kernel is preemptible, and also be batched. I'm not sure if you've had a chance to look at the POSIX.1e draft or my man pages for it. The man pages are online on by POSIX.1e page as part of the tarball containing the first pass. The API is completely documented, but I still have to document the audit event types and what they expect to be reported. 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.990412092814.11402E-100000>