From owner-freebsd-security Mon Sep 20 7:49: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from forced.attrition.org (attrition.org [198.77.217.13]) by hub.freebsd.org (Postfix) with ESMTP id C111114CC7 for ; Mon, 20 Sep 1999 07:48:57 -0700 (PDT) (envelope-from jobe@attrition.org) Received: from localhost (jobe@localhost) by forced.attrition.org (8.9.3/0.0.1.beta.nospam) with SMTP id HAA26918; Mon, 20 Sep 1999 07:42:30 -0600 Date: Mon, 20 Sep 1999 07:42:30 -0600 (MDT) From: Jobe To: ark@eltex.ru Cc: freebsd@gndrsh.dnsmgr.net, security@FreeBSD.ORG Subject: Re: Real-time alarms In-Reply-To: <199909201424.SAA01652@paranoid.eltex.spb.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 20 Sep 1999 ark@eltex.ru wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > nuqneH, > > "Rodney W. Grimes" said : > > > > > > > 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. Check his reply to my post, this is the general nature of a pseudo device =). BTW Rob, I should have a working code base for the pseudo device by the end of the day if you want to take a look. At that point we can figure out whether or not we not to do things differently. --Jobe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message