Date: Thu, 8 Aug 1996 13:59:35 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Bruce Evans <bde@zeta.org.au> Cc: jds@TracerTech.COM, Hackers@FreeBSD.org Subject: Re: kern_mib.c:int securelevel = -1; Message-ID: <Pine.SV4.3.93.960808134608.11801A-100000@parkplace.cet.co.jp> In-Reply-To: <199608072138.HAA05066@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 8 Aug 1996, Bruce Evans wrote: > > > #ifdef INSECURE > > > int securelevel = -1 > > > #else > > > int securelevel > > > #endif > > > > > > Here's the a comment from <sys/systm.h> ... > > >By the way, the comment is wrong on one important point: the disposition of > >this variable in bss vs data will be irrelevant to a cracker. If the > >kernel is not immutable, the variable can be patched either way. > > Not quite. The point is to patch the kernel that will be booted from. Personally, I'll take anything that makes it harder for a computer criminal. I agree that we shouldn't rely on these tricks, so maybe the comment can be augmented with the following: > However if the kernel is not immutable, a cracker could patch some of > the code that tests the variable. BSD/OS and NetBSD are using options INSECURE to switch this feature on and off. I'd also like to have this switch so I don't have to keep patching kern_mib.c when I build kernels that use this feature. If there are "mile wide" holes in the securelevel stuff we can state that the feature is experimental in the man pages. I still would like to have the INSECURE switch added. Just make it the default in the GENERIC kernel so it doesn't change the current default behavior. Regards, Mike Hancock
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.93.960808134608.11801A-100000>