Date: Mon, 20 Sep 1999 12:10:34 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Jobe <jobe@attrition.org> Cc: ark@eltex.ru, freebsd@gndrsh.dnsmgr.net, security@FreeBSD.ORG Subject: Re: Real-time alarms Message-ID: <Pine.BSF.3.96.990920115728.42321E-100000@fledge.watson.org> In-Reply-To: <Pine.LNX.3.96.990920085058.13128R-100000@forced.attrition.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Sep 1999, Jobe wrote: > Damn it Rob, you're taking all the fun out of my kernel projects =) I'd > still like to write this up for my own daemonic educational purposes. > Also it will give me something to kill time. Who knows, maybe you'll even > see something you like in my diffs ;). When in doubt go with my ultimate > philosophy on life as we know it, "Fear not, stranger things have > happened." Sorry :-). I'm glad however to see that there is more serious interest out there--the last few times we've discussed auditing, people haven't actually been interested in working on it, and only just willing to discuss it. :-) Go ahead and work on anything you please--I'd be glad to look at any code/diffs people come up with and this will definitely be an iterative process. One thing I am particularly interested in seeing brought to fruition is a way to protect key system security processes from interference--from any other user process, even one running as root. This might be similar to the jail code--the world being in a jail and only processes such as auditd (possibly init?) outside of it. Processes would be unable to attach debuggers to protected processes while securelevel was set above a certain value, and limited in their ability to signal the processes, etc. This would allow us to offload computationally expensive audit-related code (statistical IDS, crypto, etc) from the kernel into a user process, but also protect the user process in the event of a root compromise, complementing the securelevel behavior. In the access control email I sent earlier, tokend would be another process worthy of such protection :-). Leveraging the jail code to do this might help keep to a minimum all of the forms of process sandboxing we have. Don't know if this is a topic that interests you, but it would certainly be worthy of some hacking :-). Robert > > --Jobe > > On Mon, 20 Sep 1999, Robert Watson wrote: > > > > > I'd advise against developing any more codebases for auditing--we already > > have two :-). I have a /dev/audit, submission of records from a number of > > syscalls, an auditd + IDS interface, and some log management code. Nate's > > folk are working on a better kernel interface and implementation, as was > > discussed on freebsd-security in July (please see archive for details). > > My userland library currently supports most of the posix.1e audit > > interface spec, and I have a set of posix.1e extensions for IDS modules. > > My hope is to adapt my auditd to speak Nate's kernel improvements, but > > continue to provide a standard interface and useful tools/etc. > > > > Robert N M Watson > > > > robert@fledge.watson.org http://www.watson.org/~robert/ > > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > > TIS Labs at Network Associates, Safeport Network Services > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services 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?Pine.BSF.3.96.990920115728.42321E-100000>