From owner-freebsd-security Sun Apr 19 08:47:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA05214 for freebsd-security-outgoing; Sun, 19 Apr 1998 08:47: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 PAA05190 for ; Sun, 19 Apr 1998 15:46:52 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 IAA15927; Sun, 19 Apr 1998 08:46:37 -0700 (PDT) Received: from ns001-5.wlc.com(204.239.181.65), claiming to be "cwsys.cwsent.com" via SMTP by passer.osg.gov.bc.ca, id smtpdaapnqa; Sun Apr 19 08:46:28 1998 Received: (from uucp@localhost) by cwsys.cwsent.com (8.8.8/8.6.10) id IAA17390; Sun, 19 Apr 1998 08:46:19 -0700 (PDT) Message-Id: <199804191546.IAA17390@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpd017227; Sun Apr 19 08:45:47 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: Philippe Regnauld , freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-reply-to: Your message of "Sat, 18 Apr 1998 13:18:54 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Apr 1998 08:45:44 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > One thing that might be nice to see is a file flag that allows writes/etc > at some securelevels, but not at others. Currently, the behavior seems to > be that schg can be set at lower securelevels, but must be removed before > writes can occur. At high levels, it simply can't be removed. A new flag > might be desirable that allows changes at a lower securelevel, but > prohibits them at a high one. This could be applied to config files, for > example, allowing reconfiguration at securelevels 0, -1, but preventing > configuration of certain key files (/etc/fstab?) when the system is > actually running. 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. 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