From owner-freebsd-hackers  Wed Aug  7 22:00:15 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id WAA07335
          for hackers-outgoing; Wed, 7 Aug 1996 22:00:15 -0700 (PDT)
Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA07328
          for <Hackers@FreeBSD.org>; Wed, 7 Aug 1996 22:00:12 -0700 (PDT)
Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id EAA11883; Thu, 8 Aug 1996 04:59:35 GMT
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;
In-Reply-To: <199608072138.HAA05066@godzilla.zeta.org.au>
Message-ID: <Pine.SV4.3.93.960808134608.11801A-100000@parkplace.cet.co.jp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-hackers@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

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