From owner-freebsd-security Mon Sep 20 2:59:24 1999 Delivered-To: freebsd-security@freebsd.org Received: from forced.attrition.org (attrition.org [198.77.217.13]) by hub.freebsd.org (Postfix) with ESMTP id 8114514D30 for ; Mon, 20 Sep 1999 02:59:15 -0700 (PDT) (envelope-from jobe@attrition.org) Received: from localhost (jobe@localhost) by forced.attrition.org (8.9.3/0.0.1.beta.nospam) with SMTP id DAA22697; Mon, 20 Sep 1999 03:03:07 -0600 Date: Mon, 20 Sep 1999 03:03:07 -0600 (MDT) From: Jobe To: "Rodney W. Grimes" Cc: security@FreeBSD.ORG Subject: Re: Real-time alarms In-Reply-To: <199909200718.AAA58050@gndrsh.dnsmgr.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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