From owner-freebsd-security Tue Jul 6 2:53:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 2BA89153C6 for ; Tue, 6 Jul 1999 02:52:59 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id FAA04999; Tue, 6 Jul 1999 05:52:44 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Tue, 6 Jul 1999 05:52:44 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Darren Reed Cc: Ben Gras , freebsd-security@FreeBSD.ORG Subject: Re: how to keep track of root users? In-Reply-To: <199907011413.AAA02422@cheops.anu.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 2 Jul 1999, Darren Reed wrote: > > It appears that the process accounting in FreeBSD is a remnant of a bygone > > era, where all cpu time was costly and had to be accounted for. From a > > security perspective, process accounting would need to: > > - log uid, gid, and euid of the user calling the process. > > - log the process name, executable name, and path to the executable. > > - log arguments to the process being executed. > > - log date and amount of time the process took to complete. > > - log the tty the user who called the process executed it from. > > Process accounting provides information for what it was intended to do. > Attempting to use that information for different purposes is going to > lead you down the garden path. Process accounting is still useful, in > its current form, so `fixing' it is not the right thing to do. > > What's required here is auditting. I *think* the POSIX security module > being worked on at present is more in line with what you're aiming to > achieve. If you've got access to Solaris, checkout the man pages for > auditd, bsm, etc. Sorry for the delay in getting back to you -- I've been traveling for the last week and have just settled down in Cambridge to do a few weeks research on tamper-proof hardware :-). Indeed, I am working on a POSIX.1e auditing module for FreeBSD. I've largely completed userland libraries, and Nate Williams and myself are working on adapting the KTRACE interface to provide a nice backend for it. I have an initial version online that captures a few syscalls for the sake of demonstration, but I have a lot of new code that is currently on my notebook here in the UK, but not connected to the network. I've been playing with an intrusion detection interface for the auditing support, and have a few modules that catch the standard things (creation of setuid binaries (i.e., backdoors), etc). Similarly, I have a module that looks for long strings being passed as arguments to programs, as well as coredumps in daemons that have bound network ports. I have a simple expression language that allows a generic IDS module to watch for sets of events with certain properties, although the parser needs some more work. The problem with KTRACE is that it doesn't have a concept of discrete syscalls, it's really more of a log of events, and various kernel calls (such as namei) create log entries once in a while, which just happen to be in a useful order. We'd like to modify it to generate transactions of a sort that are discrete packages of entries in a well-defined and useful order, which can then be converted to POSIX.1e-style records for use in userland. My hope is to put a lot of this code online when I return from the UK in early August. I haven't made any forward progress in the KTRACE changes and my code largely relies on the hackish hooks in syscalls to gather data. I believe the kernel changes are the primary interest to Nate, so perhaps he could comment on how such changes could be made. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Computing Laboratory at Cambridge University Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message