Date: Mon, 20 Sep 1999 03:03:07 -0600 (MDT) From: Jobe <jobe@attrition.org> To: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> Cc: security@FreeBSD.ORG Subject: Re: Real-time alarms Message-ID: <Pine.LNX.3.96.990920011230.13128K-100000@forced.attrition.org> In-Reply-To: <199909200718.AAA58050@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Sep 1999, Rodney W. Grimes wrote: > > > > > > On Sun, 19 Sep 1999, Rodney W. Grimes wrote: > > > > *snipped* > > > > I guess it that case we need to start discussing the events that need to > > > > generate alarms. > > > > > > Slow down, your jumped from ``auditing'' to ``alarms'', as Nate points out > > > in his mail there really is 2 levels of functionality here. The in kernel > > > ``this is what I have done'' auditing mechansim, and the other side that > > > does the filtering and decides what is and is not important. It's not > > > that important where the 2 pieces live at this time, but it is important > > > to decide up front that it is 2 pieces. > > > > > > Myself, I like the idea of how bpf handles the filtering side. Compile > > > up an expression and shove it into the kernel so you minimize copy out > > > operations. > > > > > > > Also we need to look at how in depth we want to go. In > > > > addition, what are our goals here? What is it exactly that we want to be > > > > notified of. Do we consider a single 'unprivilledged' account compromise > > > > a breach of security? If so, how do you plan to go about auditing the > > > > validity of logins. I think once a list of rogue events is created we can > > > > start getting the ball rolling on this. I think it is silly to design the > > > > system before we even know what we are trying to monitor. Once we derive > > > > the events that will generate the alarms implementation of the alarming > > > > system becomes easy. It seems to me that we're trying to bake a pie with > > > > no filling here. > > > > > > I think your trying to set policy before we even have a method, though Nate > > > and Robert Watson look to have a lot of the method work done. We need to > > > go dig the differenet pieces before the group and look at what we have > > > already implemented and come up with what we want for a method. Besides > > > Nate and Roberts work there is jdp work for filesystem modification to > > > look at as well. > > > > I think my references to userland scenarios threw us off the track. > > Basically what I was trying to get at is that we really need to know what > > 'events' (in kernel happenings) that we want to be aware of. Otherwise we > > will end up developing a method for generating alarms for kernel events > > when there are no given events to generate alarms for. Do you see what > > I'm trying to get at here? Or is our primary goal to just create the > > auditing system and let the user define the events for which alarms are > > generated? > > I am trying to seperate ``method'' from ``policy''. The primary goal, IMHO, > should be to create a method of getting events from the kernel that could be > used to implement all sorts of security policies. So basically your last > statement ``create the auditing system and let the user define the events'' > is what I am after first. Then we can implement the tools that allow > the user to define the events that create alarms or what have you. Why not just have something that uses SYS_write() to write to a file possibly /dev/audit? Just have a create_alert(const char *fmt, ...) function (with accompanying va_args code) and just ship the data via SYS_write() directly to the device. Of course we'd still need to implement a method in the kernel to prevent lkms from wrapping our SYS_write(). Do we really want anyone to be able wrap SYS_write(), or many of the other syscalls, anyways? We'd also make the device appending only, etc, etc. Am I missing something again? --Jobe > > -- > Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > 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.LNX.3.96.990920011230.13128K-100000>