OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
FreeBSD Security Archives: Re: Real-time alarms

Re: Real-time alarms

Jobe (jobeattrition.org)
Mon, 20 Sep 1999 03:03:07 -0600 (MDT)

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) rgrimesgndrsh.dnsmgr.net
>
>
> To Unsubscribe: send mail to majordomoFreeBSD.org
> with "unsubscribe freebsd-security" in the body of the message
>

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

This archive was generated by hypermail 2.0b3 on Mon Sep 20 1999 - 04:59:03 CDT