Date: Mon, 20 Sep 1999 07:36:38 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: ark@eltex.ru Cc: security@FreeBSD.ORG Subject: Re: Real-time alarms Message-ID: <199909201436.HAA58981@gndrsh.dnsmgr.net> In-Reply-To: <199909201424.SAA01652@paranoid.eltex.spb.ru> from "ark@eltex.ru" at "Sep 20, 1999 06:24:01 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
-- Start of PGP signed section. > nuqneH, > > "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> 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. First the kernel does not access the daemon, the daemon accesses the kernel. Second, nothing should preclude the daemon from accessing anything else it wishes to, but trusting anything else would be dangerous. Third flexiability and security don't go well togeather. The daemon clearly would know the difference about what it opened, so that is a not an issue. If we write an ``audit protocol'' it could be spoken over any socket, so that is probably a good flexiable approach. -- 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?199909201436.HAA58981>