Date: Sat, 18 Apr 1998 13:18:54 -0400 (EDT) From: Robert Watson <robert@cyrus.watson.org> To: Philippe Regnauld <regnauld@deepo.prosa.dk> Cc: freebsd-security@FreeBSD.ORG Subject: Re: kernel permissions Message-ID: <Pine.BSF.3.96.980418131307.15725F-100000@trojanhorse.pr.watson.org> In-Reply-To: <19980417105557.59439@deepo.prosa.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980418131307.15725F-100000>