From owner-freebsd-security Sun Apr 19 11:10:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA06405 for freebsd-security-outgoing; Sun, 19 Apr 1998 11:10:32 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (root@FLEDGE.RES.CMU.EDU [128.2.91.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA06359 for ; Sun, 19 Apr 1998 18:10:13 GMT (envelope-from robert@cyrus.watson.org) Received: from trojanhorse.pr.watson.org (trojanhorse.pr.watson.org [192.0.2.10]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id OAA24751; Sun, 19 Apr 1998 14:09:57 -0400 (EDT) Date: Sun, 19 Apr 1998 14:09:43 -0400 (EDT) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: Cy Schubert - ITSD Open Systems Group cc: Philippe Regnauld , freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-Reply-To: <199804191546.IAA17390@cwsys.cwsent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Sun, 19 Apr 1998, Cy Schubert - ITSD Open Systems Group wrote: > This would negate the effectiveness of securelevels and the schg flag. > The reason for only allowing updates at securelevels <= 0 is that you > need to be in single user state to alter files that are deemed > critical, e.g. schg flag, by the sysadmin. If you can only update > these files in single user state and single user state requires that > you be next to the machine working at the console, then a hacker would > have a more difficult time altering files deemed critical to site > security. > > If the proposed flag is tied directly to the network interfaces, e.g. > if the flag allowing the schg flag or files with schg flags to be > altered at a specified securelevel, then network interfaces should be > automatically be disabled at that securelevel or lower. > > In short, back doors = exploits. I think I may not have expressed my proposal in the best possible way. My intent was to increase the number of securelevels used by the system during boot, layering the various setup and startup activities that normally happen, trying to work out dependencies, etc. I.e., the first section of rc involves mounting filesystems -- this relies on the contents of mount_*, fstab, possibly some lkms, and so on. Presumably this phase of the boot is in securelevel -1. These files are flagged such that they may be modified only at or before a specific securelevel, and as with now, securelevels can only go up. I'm not sure of the details yet, but for a machine not relying on DHCP/NFS partitions (rely==root, usr, etc) the 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 It was also my thought that some network interface configuration might be locked down above a certain securelevel. In the case of a firewall machine, wouldn't it be great if, even thought there was a root compromise, the attacker could not make any connections to the internal network, and couldn't even do anything as simple as change the interface's IP address or routing? :) Robert N Watson ---- Carnegie Mellon University http://www.cmu.edu/ Trusted Information Systems 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 security" in the body of the message