From owner-freebsd-current Thu Sep 10 10:15:18 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA08093 for freebsd-current-outgoing; Thu, 10 Sep 1998 10:15:18 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from fledge.watson.org (COPLAND.CODA.CS.CMU.EDU [128.2.222.48]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA08088 for ; Thu, 10 Sep 1998 10:15:17 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id NAA28063; Thu, 10 Sep 1998 13:14:13 -0400 (EDT) Date: Thu, 10 Sep 1998 13:14:13 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Bruce Evans cc: mark@grondar.za, tlambert@primenet.com, current@FreeBSD.ORG, max@wide.ad.jp Subject: Re: unremovable schg flag? In-Reply-To: <199809100925.TAA09021@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 10 Sep 1998, Bruce Evans wrote: > >> > After struggling for some time, I went into the single user mode > >> > and clri'd that file. > > This shows that securelevel 1 isn't actually secure. (Starting from > the uninitialized shell variable kern_securelevel, /etc/rc sets the > kernel securelevel to 0. init(8) knows too much about securelevels > and bumps this to 1. Level 1 is a little bit insecure.) FreeBSD with secure levels is not secure, as the disk layout and binaries are not architected with securelevels as a goal. I have some discussion on my web page, but the main issue is that any binary run (or related config file) in a low secure level must be protected against modification by processes in a higher secure level. For example, to protect the securelevel setting mechanism: 1) init must be schg 2) /sbin holding init must be schg 3) /kernel mus tbe schg 3) /bin/sh (the shell used to run rc) must be schg 4) /etc/rc must be schg 5) Any bins run by /etc/rc before bumping the securelevel (including sysctl) must be schg You can pretty much apply this to any file touched prior to the bump. Similarly, remounting file systems should be prohibited above a certain securelevel. I believe directly modifying disk devices is already prohibited in high securelevels. However, there is no good way to protect single-user mode, as that assumes local console access to the machine. And there is little if anything one can do to protect against a local user (except to protect against the uninitiated :). Robert N Watson Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ robert@fledge.watson.org http://www.watson.org/~robert/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message