Date: Sun, 19 Sep 1999 23:29:23 -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: <199909200629.XAA57821@gndrsh.dnsmgr.net> In-Reply-To: <Pine.LNX.3.96.990919225507.13128G-100000@forced.attrition.org> from Jobe at "Sep 19, 1999 11:05:16 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
[Back on list, this was sent to me privately, I think by mistake though] > > On Sun, 19 Sep 1999, Rodney W. Grimes wrote: > > > However, the implementation of an auditing system should be doable > > pretty easily in the current system and gain us some functionality > > that we do not have, and should not need to be changed drastically > > if or when per process/user privilege becomes a reality, other than > > it will probably take a privilege to access /dev/audit :-). > > > > So lets get back on track and talk about how to implement a real time > > auditing system in the kernel. Lets forget about any user land consumers > > of this interface, other than to design the interface in as secure manner > > as can be given the tools we have today. Lets forget about email and > > networks, and transports and all that stuff that we already know are > > not securable _at_ _this_ _time_, and get on with /dev/audit. > > 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. Basically in the VMS SYS$AUDIT world you could monitor just about everything, I don't think we should predefine a limiting set, it'll only get expanded over and over. We need to do some research and get as much public detail as is avaliable on as many auditing implementations as we can. Then write a book on what is out there, then implement something better... :-) :-) :-). We do atleast need to take a look around... -- 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?199909200629.XAA57821>