From owner-freebsd-security Sun Apr 19 12:42:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA25916 for freebsd-security-outgoing; Sun, 19 Apr 1998 12:42:01 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from passer.osg.gov.bc.ca (0@passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA25773 for ; Sun, 19 Apr 1998 19:41:46 GMT (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id MAA16745; Sun, 19 Apr 1998 12:41:37 -0700 (PDT) Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by passer.osg.gov.bc.ca, id smtpdaaqkra; Sun Apr 19 12:41:28 1998 Received: (from uucp@localhost) by cwsys.cwsent.com (8.8.8/8.6.10) id MAA23123; Sun, 19 Apr 1998 12:41:25 -0700 (PDT) Message-Id: <199804191941.MAA23123@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpd023111; Sun Apr 19 12:40:33 1998 X-Mailer: exmh version 2.0.1 12/23/97 Reply-to: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: cy To: Robert Watson cc: Cy Schubert - ITSD Open Systems Group , Philippe Regnauld , freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-reply-to: Your message of "Sun, 19 Apr 1998 14:09:43 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Apr 1998 12:40:31 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > > I think I may not have expressed my proposal in the best possible way. My O.K. > following might work: > > -1 - fsck, mount first few file systems, clean up mess > 0 - install ipfw filters, start logging daemons, etc > 1 - ... (lock down on mount changes) > 2 - ... (lock down on network config changes) > (etc) > x - raise network interfaces The BSD kernel normally starts out at securelevel 0. Once init has initialized, e.g. run the rc scripts, the kernel automatically raises the securelevel to 1 if it hasn't been raised to a higher securelevel. Securelevel -1 is a special case. If securelevel -1 is hard coded into the kernel, as is done in FreeBSD, the kernel will not automatically raise the securelevel. In short, securelevel -1 tells the kernel to leave the system at a securelevel 0 state permanently. What you're suggesting here is breaking the existing semantics. Currently the securelevel semantics are, -1 = permanently insecure mode, always run at securelevel 0 regardless of the system state (this must be compiled in the kernel, otherwise securelevel 0 is used during boot) 0 = temporarily insecure mode, immutable and append-only flags may be turned off; and all devices may be read/written. 1 = secure mode, immutable and append-only flags cannot be cleared, mounted disks and kernel memory are read-only. 2 = highly secure mode, same as securelevel 1 except all disks are read-only regardless whether they are mounted or not. For this discussion securelevel -1 is irrelevant. Securelevels > 2 are not defined, however as stated earlier in this discussion the kernel does disallow altering of the ipfw configuration at securelevel > 2. I would think that the designers of the BSD kernel probably had planned to expand on the securelevels in a future release, had they had the opportunity to. What does all of this mean? It is clear to see that the BSD designers had only documented filesystem semantics when describing securelevels. We also see from the example quoted from ip_fw.c that securelevels > 2 were being considered by the BSD designers. Is it possible that securelevels 0-2 are to address local security and securelevels > 2 are to address network security. Here is an alternative strawman, -1 - permanently insecure, never used on a secure box (used for most desktops and home systems) 0 - insecure mode, start all daemons, mount all filesystems 1 - BSD secure mode (described above) 2 - BSD highly secure mode (described above) 3 - Network secure mode, ipfw and network interfaces cannot be altered after they have been raised, routing tables cannot be altered 4 - Ultra secure mode: /, /usr, /opt remounted read-only (by the kernel), no mounts/umounts possible, raw disk devices cannot be read, NFS requests no longer honoured 5 - Ultra Ultra (for the lack of a better name) secure mode, stack becomes non-executable don't honour setuid bit (?), arp cache can no longer be altered (?) ... - and so on... Any thoughts? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Open Systems Group Internet: cschuber@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Government of BC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message