Date: Thu, 8 Jul 1999 05:30:21 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Nate Williams <nate@mt.sri.com> 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: <Pine.BSF.3.96.990708052148.17458B-100000@fledge.watson.org> In-Reply-To: <199907061713.LAA14163@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 6 Jul 1999, Nate Williams wrote: > [ 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. My feeling is that perhaps KTRACE should be initially modified so that records for a particular context (that is, when entering kernel mode, a particular syscall) should be buffered in some way associated with the context, and then "commit" could be called in the syscall return (or signal return, etc), resulting in the records being flushed to the KTRACE management routines. This would have the effect of gathering related records. We could then work from there to structure the gathering procedure or tag entries in some useful way. > > 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. This sounds good to me :-). > > 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). As I pointed out in a prior email, one immediate problem is that namei submits the KTRACE entry for pathname arguments that undergo name lookups. As a result, my syscall patches end up copying in the argument a second time. This is clearly a problem if shared memory is allows between contexts, as there are race conditions. Similarly, it's also fairly inefficient. It's not clear to me what the best solution is: we could either move the copyin out of namei and submit the path via an argument, or we could provide an argument to namei that allows it to tag its KTRACE submission appropriately. It seems to me that initially two changes, then, are necessary: modifying KTRACE to submit in bundles of records associated with individual events, and modifying KTRACE to allow tagging of submitted entries as particular components of an event. We can then propagate the changes up so that the various locations submitting KTRACE entries tag the entries correctly. > ps. How's Cambridge? Going well. I've been here for a few days now, and am helping to set up their tamper-resistant hardware lab. I'm in the process of learning some new machine languages for some embedded chips. I'll then code some crypto algorithms for the chips and we'll start doing power analysis on the chips during various instructions and see if we can pull data out of the chips based on the power consumption. I don't have much experience with hardware security, so I'm learning a lot. I'm not sure how much they're getting out of this, but it's fun. Should keep me busy for a couple of weeks while I'm here. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.990708052148.17458B-100000>