From owner-freebsd-security Tue Jul 6 10:13:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (unknown [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 6B98B14C2F for ; Tue, 6 Jul 1999 10:13:47 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id LAA20810; Tue, 6 Jul 1999 11:13:35 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA14163; Tue, 6 Jul 1999 11:13:33 -0600 Date: Tue, 6 Jul 1999 11:13:33 -0600 Message-Id: <199907061713.LAA14163@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Watson Cc: Darren Reed , Ben Gras , freebsd-security@FreeBSD.ORG Subject: Re: how to keep track of root users? In-Reply-To: References: <199907011413.AAA02422@cheops.anu.edu.au> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ Intrusion detection ] > 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. Which happen to be in a useful order in a UP kernel. On an SMP kernel all bets are off, and a solution that doesn't work on SMP (or works because of quirks in the current SMP implementation) aren't acceptable IMO. > 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. Agreed. However, all ideas that I have come up with (so far) involve more changes to the kernel sources than I'm comfortable with, so I'm trying to think of a new strategy that doesn't require large-scale changes to the entire kernel. If we have too many changes, the chance of rejection by the kernel gurus are high, and I don't have the time or desire to spend months/years going through an iterative process to make them palatable, all the while hand-maintaining them while the kernel goes through revolutionary changes for SMP support that I forsee are going to occur. > 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. These are the 'easy' way to do things, and *may* be the only sane way to do things. However, it requires alot of work for anyone modifying the kernel to keep things straight (this isn't overly bad), but it requires anyone adding a new syscall to add this in, and this 'requirement' may not be followed. It would be nicer if this could somehow be 'automated' like it is in KTRACE currently, but I haven't thought of a good way (yet). Nate ps. How's Cambridge? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message