Date: Mon, 20 Sep 1999 11:05:01 -0600 From: Nate Williams <nate@mt.sri.com> To: ark@eltex.ru Cc: freebsd@gndrsh.dnsmgr.net, security@FreeBSD.ORG Subject: Re: Real-time alarms Message-ID: <199909201705.LAA01318@mt.sri.com> In-Reply-To: <199909201424.SAA01652@paranoid.eltex.spb.ru> References: <199909201416.HAA58893@gndrsh.dnsmgr.net> <freebsd@gndrsh.dnsmgr.net> <199909201424.SAA01652@paranoid.eltex.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > > > Hmmm, i think it is a good idea to have 2 kernel interfaces: > > > > > > 1) audit - one way communication system that lets kernel and possibly > > > some user processes to inform an audit daemon or whatever that something > > > important happened > > > > By definision a secure audit trail can only be generated by a secure > > code base, that pretty much precludes any user processes from being > > a source of data at this time. > > What about "2-in-one" interface that could be accessed from kernel and > from userspace but provides functions that will let audit daemon to > know the difference? That can make things more flexible. This is Robert's goal as well, but secondary to my goals. But if/when it happens, I will argue for a completely different queue for userland events, and not allow the userland events get close to the kernel events. 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?199909201705.LAA01318>