Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 17 Nov 1999 14:02:11 +0100 (CET)
From:      root@d074.paris-222.cybercable.fr
To:        FreeBSD-gnats-submit@freebsd.org
Subject:   kern/14941: /etc/init vs kern.securelevel incoherence
Message-ID:  <199911171302.OAA00956@d074.paris-222.cybercable.fr>

next in thread | raw e-mail | index | archive | help

>Number:         14941
>Category:       kern
>Synopsis:       /etc/init vs kern.securelevel incoherence
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Nov 17 05:10:00 PST 1999
>Closed-Date:
>Last-Modified:
>Originator:     Cyrille Lefevre
>Release:        FreeBSD 3.3-STABLE i386
>Organization:
ACME
>Environment:

FreeBSD gits 3.3-STABLE FreeBSD 3.3-STABLE #5: Sun Nov 14 04:01:58 CET 1999	root@gits:/disk3/3.3-STABLE/src/sys/compile/CUSTOM  i386

>Description:

	the init(8) manual says :

	Any super-user process can raise the security level, but only
	init can lower it.
	...
	If the security level is initially -1, then init leaves it
	unchanged.  Otherwise, init arranges to run the system in
	level 0 mode while single-user and in level 1 mode while
	multi-user. 

	but in the kernel says :

	in function sysctl_kern_securelvl in /sys/kern/kern_mib.c :

		if (securelevel > 1 && level < securelevel)
			return (EPERM);

	as well as the sysctl(3) manual and some other docs :

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

	so, if you have a security level greater or equal to 1,
	even when going to single-user mode, you cannot lower
	the security level to 0 to install a new kernel and you
	have reboot into single-user or to set the
	kern_securelevel_enable to NO in the /etc/rc.conf file,
	then reboot.

>How-To-Repeat:

	in /etc/rc.conf :

	kern_securelevel_enable="YES"
	kern_securelevel="0"

	boot to multi-user mode then switch to single user mode using :

	init 1

	you got a syslog message saying :

	cannot change kernel security level from 1 to 0: Permission denied.

>Fix:

# diff -rcb kern_mib.c.orig kern_mib.c
*** kern_mib.c.orig	Wed Nov 17 03:16:52 1999
--- kern_mib.c	Wed Nov 17 03:22:46 1999
***************
*** 138,144 ****
		error = sysctl_handle_int(oidp, &level, 0, req);
		if (error || !req->newptr)
			return (error);
!		if (level < securelevel)
			return (EPERM);
		securelevel = level;
		return (error);
--- 138,148 ----
		error = sysctl_handle_int(oidp, &level, 0, req);
		if (error || !req->newptr)
			return (error);
! #ifdef notdef
!		printf ("pid=%d curproc=%p initproc=%p\n",
!			curproc->p_pid, curproc, initproc);
! #endif
!		if (curproc != initproc && level < securelevel)
			return (EPERM);
		securelevel = level;
		return (error);

a much portable solution would be :

# diff -rcb kern_mib.c.orig kern_mib.c
*** kern_mib.c.orig	Wed Nov 17 03:16:52 1999
--- kern_mib.c	Wed Nov 17 03:22:46 1999
***************
*** 138,144 ****
		error = sysctl_handle_int(oidp, &level, 0, req);
		if (error || !req->newptr)
			return (error);
!		if (level < securelevel)
			return (EPERM);
		securelevel = level;
		return (error);
--- 138,148 ----
		error = sysctl_handle_int(oidp, &level, 0, req);
		if (error || !req->newptr)
			return (error);
! #ifdef notdef
!		printf ("pid=%d curproc=%p initproc=%p\n",
!			curproc->p_pid, curproc, initproc);
! #endif
!		if (curproc->p_pid != 1 && level < securelevel)
			return (EPERM);
		securelevel = level;
		return (error);

>Release-Note:
>Audit-Trail:
>Unformatted:


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911171302.OAA00956>