Date: Thu, 8 Jul 1999 10:45:25 -0600 From: Nate Williams <nate@mt.sri.com> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: Nate Williams <nate@mt.sri.com>, 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: <199907081645.KAA29163@mt.sri.com> In-Reply-To: <Pine.BSF.3.96.990708052148.17458B-100000@fledge.watson.org> References: <199907061713.LAA14163@mt.sri.com> <Pine.BSF.3.96.990708052148.17458B-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. > > 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. There are other issues with the KTRACE facility that have come up. Most notably, for IDS systems, you need a *LOT* more information than KTRACE provides. For example, in the exec() syscall, not only do you want the argument of the file you are exec'ing, you also want the file permissions, size, ownership, gid of the user, mount flags of the FS (it may be NO_EXEC of NO_SUID) so you can do proper detection. None of this information is provided via KTRACE, and according to our IDS expert, it's necessary to do proper detection. > > > 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 :-). I'm of the opinion that to make truly useful IDS records, we're going to have to make some significant changes to the FreeBSD kernel. Note, these changes are only going to affect folks who ask for kernel auditing (not KTRACE), but because of the type and quantity of information desired in IDS systems, it will cause a performance hit in those systems that desire it. > > > 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. I'm beginning to think that using KTRACE is not an acceptable way of doing things, and that we need to re-instrument the kernel with IDS auditing on it's own. In other words, your current strategy of instrumenting individual syscalls is the 'correct' approach, although it leaves the potential for modifying large portions of the system and the possibility that as new syscall are added they will not be instrumented correctly, or at all. Unfortunately, I don't see any way around this if we want useful IDS records. I also don't know how well the FreeBSD kernel guys are going to take having almost every kernel source file modified in an attempt to 'slow down' the system to get IDS information. :) Nate 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?199907081645.KAA29163>