From owner-freebsd-hackers Wed Aug 7 09:30:31 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA14212 for hackers-outgoing; Wed, 7 Aug 1996 09:30:31 -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 JAA14191 for ; Wed, 7 Aug 1996 09:30:27 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id QAA07632 for ; Wed, 7 Aug 1996 16:30:18 GMT Date: Thu, 8 Aug 1996 01:30:18 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: FreeBSD Hackers Subject: kern_mib.c:int securelevel = -1; Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk It looks like the assignment of securelevel was put into kern_mib.c from kern_sysctl.c. This is ok I guess, but I'd like to have an option INSECURE that we can turn off... #ifdef INSECURE int securelevel = -1 #else int securelevel #endif Here's the a comment from ... * Security levels are as follows: * -1 permanently insecure mode - always run system in level 0 mode. * 0 insecure mode - immutable and append-only flags make be turned off. * All devices may be read or written subject to permission modes. * 1 secure mode - immutable and append-only flags may not be changed; * raw disks of mounted filesystems, /dev/mem, and /dev/kmem are * read-only. * 2 highly secure mode - same as (1) plus raw disks are always * read-only whether mounted or not. This level precludes tampering * with filesystems by unmounting them, but also inhibits running * newfs while the system is secured. * * In normal operation, the system runs in level 0 mode while single user * and in level 1 mode while multiuser. If level 2 mode is desired while * running multiuser, it can be set in the multiuser startup script * (/etc/rc.local) using sysctl(1). If it is desired to run the system * in level 0 mode while multiuser, initialize the variable securelevel * in /sys/kern/kern_sysctl.c to -1. Note that it is NOT initialized to * zero as that would allow the kernel binary to be patched to -1. * Without initialization, securelevel loads in the BSS area which only * comes into existence when the kernel is loaded and hence cannot be * patched by a stalking hacker. */ Can someone commit this please? Regards, Mike Hancock