Date: Mon, 20 Sep 1999 00:18:27 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: jobe@attrition.org (Jobe) Cc: security@FreeBSD.ORG Subject: Re: Real-time alarms Message-ID: <199909200718.AAA58050@gndrsh.dnsmgr.net> In-Reply-To: <Pine.LNX.3.96.990920000340.13128J-100000@forced.attrition.org> from Jobe at "Sep 20, 1999 00:11:07 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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. -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909200718.AAA58050>