Date: Mon, 20 Sep 1999 07:26:33 -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: <199909201426.HAA58947@gndrsh.dnsmgr.net> In-Reply-To: <Pine.LNX.3.96.990920011230.13128K-100000@forced.attrition.org> from Jobe at "Sep 20, 1999 03:03:07 am"
next in thread | previous in thread | raw e-mail | index | archive | help
[Snip] > > > 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? Your missing the fact that SYS_write is a system call from userland into the kernel. The data flow of /dev/audit is the other way. Try something more like /dev/audit is a kernel psuedo device implemented more like /dev/klog or a socket implemented more like route(4). And by thier nature these they are append only devices... And you can't implement any protection from wrapping, lkm or kld's, thats impossible with the current security model that would need changed with the creation of a secure code base, implementation of per process privileges, etc. That should be deligated to another larger project that can be developed pre, concurrent, or post auditing system creation. Think KISS really hard! -- 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?199909201426.HAA58947>