From owner-freebsd-security Sat Apr 18 10:19:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA21866 for freebsd-security-outgoing; Sat, 18 Apr 1998 10:19:15 -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 RAA21830 for ; Sat, 18 Apr 1998 17:19:04 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 NAA04751; Sat, 18 Apr 1998 13:19:00 -0400 (EDT) Date: Sat, 18 Apr 1998 13:18:54 -0400 (EDT) From: Robert Watson X-Sender: robert@trojanhorse.pr.watson.org Reply-To: Robert Watson To: Philippe Regnauld cc: freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions In-Reply-To: <19980417105557.59439@deepo.prosa.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Fri, 17 Apr 1998, Philippe Regnauld wrote: > Suggestion: how difficult would it be to have ipfw(8) respect > the securelevel to, for example, refuse to flush / alter > the ipfw list ? > > i.e.: all mods have to be tested before the securelevel is raised, > and once it is, only rebooting into single user on the console > allows you to change the filters. Having just browsed the kernel source a little, it looks like indeed this is currently implemented. The comment is a little obscure: /* only allow get calls if secure mode > 2 */ if (securelevel > 2) { if (m) (void)m_free(m); return(EPERM); But what it actually means is, only allow non-get calls if securemode > 2. The following indeed does restrict ipfw writing: thithle:/etc# sysctl -w kern.securelevel=50 kern.securelevel: -1 -> 50 thithle:/etc# thithle:/etc# ipfw list ... thithle:/etc# ipfw flush Are you sure? [yn] y ipfw: setsockopt(IP_FW_FLUSH): Operation not permitted thithle:/etc# ipfw add 01001 allow ip from any to any via lo0 01001 allow ip from any to any via lo0 ipfw: setsockopt(IP_FW_ADD): Operation not permitted The behavior seems to be correct already. One problem I'm seeing in a few places is a lack of clarity as to what various securelevels should imply. Part of the problem seems to be that it is a one-dimmensional name space. 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. Have I missed an existing flag that already works this way? :) 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