Date: Mon, 20 Sep 1999 00:05:27 -0600 From: Nate Williams <nate@mt.sri.com> To: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> Cc: security@FreeBSD.ORG Subject: Re: Real-time alarms Message-ID: <199909200605.AAA28878@mt.sri.com> In-Reply-To: <199909200547.WAA57682@gndrsh.dnsmgr.net> References: <Pine.LNX.3.96.990919193527.13128E-100000@forced.attrition.org> <199909200547.WAA57682@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Rodney W. Grimes writes: > So lets get back on track and talk about how to implement a real time > auditing system in the kernel. Been there, doing that. Also, I spoke with Robert Watson earlier in the day, and we're going to see how easy it will be to 'merge' our work, since it appears we've been working on different thing. I'm calling him this week sometime and we'll chat about our existing implementation and see how we can work together instead of in paralle. on the same tasks. For now, I'm keeping the details offline, since there's still *lots* of things to do, and very little time to get something that works finished. I don't have time for everyone's pet feature, since I *have* to have something up and working before the end of the year (and that includes a user-land consumer -> proprietary conversion program done) for work. So, in summary, a working /dev/audit is in progress *right now* (I've got code and everything ;) and it *will* be finished before the first of the year since it's for Real Work (tm). My (SRI's) portion *ONLY* deals with the kernel, and does nothing with the userland. Robert has some great ideas as well as some code that could be used to generate audit records for userland code (login, su, etc...), but that's of lesser importance to my employer, so it's on my back-burner until the kernel stuff gets finished. Now, whether or not the FreeBSD Project decides to accept this work is another thing in itself, but my secondary goal (next to getting it done. :) is to attempt to build it in such a way that it will be acceptable to 'the powers that be'. I think we have a design that will eventually be accepted with a few iterations, which is beneficial to my employer as well as to FreeBSD. Finally, just to throw folks a bone, my *primary* design consideration for /dev/audit is speed. The original design contains *NO* filtering capability (all or nothing), and trades memory for speed, with the assumption that generating records is going to be fairly costly in terms of data copying into the 'audit record' in both the kernel and then again when the data is moved out to userland. Also, *EVERY* syscall is going to be audited, so as you can imagine there is going to be some overhead involved, and minimizing that overhead is a secondary goal. The first cut is based heavily on KTRACE (as a matter of fact, KTRACE is a pre-requisite). This may/may not be the version that ends up in FreeBSD, but it allowed to effect the least amount of files, as well as build upon an already existing and well-known capability in FreeBSD. Unfortunately, it's not completely adequate for the task, but it's goes a long way towards auditing the entire kernel. Nate 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?199909200605.AAA28878>