From owner-freebsd-security Sun Jun 9 09:14:20 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA08095 for security-outgoing; Sun, 9 Jun 1996 09:14:20 -0700 (PDT) Received: from post.io.org (post.io.org [198.133.36.6]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA08089 for ; Sun, 9 Jun 1996 09:14:17 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by post.io.org (8.7.5/8.7.3) with SMTP id MAA12561 for ; Sun, 9 Jun 1996 12:13:19 -0400 (EDT) Date: Sun, 9 Jun 1996 12:13:24 -0400 (EDT) From: Brian Tao To: FREEBSD-SECURITY-L Subject: Effects of kern.securelevel >= 0 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk According to /sys/sys/systm.h, single user mode should be associated with kern.securelevel=0 and multiuser mode with kern.securelevel=1. Should the default /etc/rc have the appropriate sysctl call? Also, are there any caveats to running an ISP shell login server with securelevel 2? I recall that an old version of XFree86 would complain at level 1+ because it seemed to want to write to /dev/mem (VGA memory access?). I can't think of any side effects (no user should be fiddling with raw disk devices anyway). My main concern was the ability to turn off schg/sappnd flags at level -1 or 0. I suppose, however, that if someone was able to execute commands as root, that person could just add commands to /etc/rc to do their dirty deeds and reboot the machine... :( /* * The `securelevel' variable controls the security level of the system. * It can only be decreased by process 1 (/sbin/init). * * 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. */ -- Brian Tao (BT300, taob@io.org, taob@ican.net) Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't"