Date: Sun, 19 Apr 1998 14:09:43 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Cy Schubert - ITSD Open Systems Group <cschuber@uumail.gov.bc.ca> Cc: Philippe Regnauld <regnauld@deepo.prosa.dk>, freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions Message-ID: <Pine.BSF.3.96.980419132625.18223B-100000@trojanhorse.pr.watson.org> In-Reply-To: <199804191546.IAA17390@cwsys.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980419132625.18223B-100000>