Date: Tue, 6 Jul 1999 11:13:33 -0600 From: Nate Williams <nate@mt.sri.com> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: Darren Reed <avalon@coombs.anu.edu.au>, Ben Gras <ben@nl.euro.net>, freebsd-security@FreeBSD.ORG Subject: Re: how to keep track of root users? Message-ID: <199907061713.LAA14163@mt.sri.com> In-Reply-To: <Pine.BSF.3.96.990706054644.296B-100000@fledge.watson.org> References: <199907011413.AAA02422@cheops.anu.edu.au> <Pine.BSF.3.96.990706054644.296B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907061713.LAA14163>