Date: Fri, 17 Sep 1999 23:24:07 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: imp@village.org (Warner Losh) Cc: wes@softweyr.com (Wes Peters), brett@lariat.org (Brett Glass), security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel Message-ID: <199909180624.XAA50611@gndrsh.dnsmgr.net> In-Reply-To: <199909180612.AAA00597@harmony.village.org> from Warner Losh at "Sep 18, 1999 00:12:30 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> In message <37E32365.B9F9573B@softweyr.com> Wes Peters writes: > : Worked for me. A well-written, accurate analogy too. > > I'll have to try again later... I'd be very interested in this. I > personally think that schg is useful against accidental mistakes, but > flawed in implementation. > > Although some of that may be due to inperfections in /etc/rc and > friends. Once you read the article you will see just how flawed ``schg'' is. It only attempts to prevent action, it does not send out any alarms. The propasal that jdp has on a socket sort of notification facility for all file system modifications is a long was ahead of what could ever be done with schg, as that tool would give us the ability to real time audit even attempts at cracking on the system. ACF2 in the mainframe world, and the VMS AUDIT tools are good examples of what can be done with this type of feature. Real time alarms if someone even _tries_ to modify a schg file is what is missing... someone turning off schg on a file is another thing missing... or accessing the disk through the raw device to reset the bit, etc, etc... -- 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?199909180624.XAA50611>