Bug 20974

Comment 1 Chris D.Faulhaber 2000-09-01 13:22:47 UTC

Responsible Changed
From-To: gnats-admin->freebsd-bugs

Misfiled PR

Comment 2 Sheldon Hearn 2000-09-01 13:34:46 UTC

State Changed
From-To: open->feedback

Could you quote the part of the init(8) manual page that you're 
talking about.  All I see is this: 

| 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.  If level 2 mode is desired 
| while running multi-user, it can be set while single-user, e.g., in the 
| startup script /etc/rc, using sysctl(8) to set the ``kern.securelevel'' 
| variable to the required security level.

On Fri, 01 Sep 2000 12:33:12 -0400, Vivek Khera wrote:

> s> | If the security level is initially -1, then init leaves it unchanged.
> s> | Otherwise, init arranges to run the system in level 0 mode while single-
> s> | user and in level 1 mode while multi-user.  If level 2 mode is desired
> s> | while running multi-user, it can be set while single-user, e.g., in the
> s> | startup script /etc/rc, using sysctl(8) to set the ``kern.securelevel''
> s> | variable to the required security level.
> 
> Yes.  I read that paragraph to mean that if I set securelevel to
> something other than -1 from /etc/rc, that init will pull it back to
> level 0 when I go to single-user mode.  That does not happen.

I think you're misunderstanding.  The page is talking about the
transition from single-user mode to multi-user mode (part of init's
job).  There's no mention of the transition back to single-user mode.

Ciao,
Sheldon.

>>>>> "SH" == Sheldon Hearn <sheldonh@uunet.co.za> writes:

SH> I think you're misunderstanding.  The page is talking about the
SH> transition from single-user mode to multi-user mode (part of init's
SH> job).  There's no mention of the transition back to single-user mode.

 "init arranges to run the system in level 0 mode while single-
 user and in level 1 mode while multi-user."

This sentence does not imply any direction.  It just says that in
single user mode you'll get level 0 and in multi-user mode you'll get
level 1.

I also don't understand how to not have the initial mode be -1 so that
init will do this, since by the time /etc/rc is run to alter the mode,
init is already running.  There is no option in the kernel LINT file
to set the initial mode.

It sure is hard to do system maintenance unless the secure level drops
back to 0 in single user mode.  BSD/OS does this, and it makes sense
to do so, I think.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D.                Khera Communications, Inc.
Internet: khera@kciLink.com       Rockville, MD       +1-301-545-6996
GPG & MIME spoken here            http://www.khera.org/~vivek/

Comment 5 Sheldon Hearn 2000-09-04 08:27:16 UTC

State Changed
From-To: feedback->open

Okay, I see where I'm going wrong.  I'm arguing that the manual 
page is not inaccurate.  The originator is arguing that  
FreeBSD doesn't handle securelevel on return to single-user 
mode the same way that BSD/OS does and maintains that the 
BSD/OS behaviour is more useful.

On Sun, 03 Sep 2000 08:30:06 MST, Vivek Khera wrote:

>  It sure is hard to do system maintenance unless the secure level drops
>  back to 0 in single user mode.  BSD/OS does this, and it makes sense
>  to do so, I think.

The CVS logs for init.c revealed something interesting:

| revision 1.36
| date: 1999/09/06 08:41:32;  author: kato;  state: Exp;  lines: +1 -7
| FreeBSD kernel doesn't allow any process to decrease securelevel. So,
| init(8) cannot decrease securelevel.  The manual page explains this
| and single_user() doesn't try to downgrade kernel to insecure mode.
| 
| Reviewed by:	bde (manual page)

As I said before, I don't think that the manual page describes the
reality of the sitation.

So now the issue is whether we want to allow the same behaviour as
BSD/OS exhibits, and if so, how to teach the kernel to allow the
dropping of the securelevel.

Ciao,
Sheldon.

Sheldon Hearn writes:
> The following reply was made to PR bin/20974; it has been noted by GNATS.
> 
> From: Sheldon Hearn <sheldonh@uunet.co.za>
> To: Vivek Khera <khera@kcilink.com>
> Cc: freebsd-gnats-submit@freebsd.org
> Subject: Re: bin/20974: securelevel not reset when going to single user mode 
> Date: Mon, 04 Sep 2000 13:39:46 +0200
> 
>  On Sun, 03 Sep 2000 08:30:06 MST, Vivek Khera wrote:
>  
>  >  It sure is hard to do system maintenance unless the secure level drops
>  >  back to 0 in single user mode.  BSD/OS does this, and it makes sense
>  >  to do so, I think.
>  
>  The CVS logs for init.c revealed something interesting:
>  
>  | revision 1.36
>  | date: 1999/09/06 08:41:32;  author: kato;  state: Exp;  lines: +1 -7
>  | FreeBSD kernel doesn't allow any process to decrease securelevel. So,
>  | init(8) cannot decrease securelevel.  The manual page explains this
>  | and single_user() doesn't try to downgrade kernel to insecure mode.
>  | 
>  | Reviewed by:	bde (manual page)
>  
>  As I said before, I don't think that the manual page describes the
>  reality of the sitation.
>  
>  So now the issue is whether we want to allow the same behaviour as
>  BSD/OS exhibits, and if so, how to teach the kernel to allow the
>  dropping of the securelevel.

I propose change via options in config file,
because current state is very useful

>  Ciao,
>  Sheldon.

-- 
@BABOLO      http://links.ru/

On Tue, 05 Sep 2000 06:07:23 +1100, Bruce Evans wrote:

> Some more updates are needed.

As far as this PR is concerned, about the best improvement I can think
of for the securelevel misunderstanding is included below.  I don't
think that the manual page is lacking right now, but this patch causes
it to state the situation explicitly.

Ciao,
Sheldon.

Index: init.8
===================================================================
RCS file: /home/ncvs/src/sbin/init/init.8,v
retrieving revision 1.22
diff -u -d -r1.22 init.8
--- init.8	2000/03/01 11:27:06	1.22
+++ init.8	2000/09/05 11:48:03
@@ -93,6 +93,8 @@
 .Pp
 The kernel runs with four different levels of security.
 Any super-user process can raise the security level, but no process
+(including
+.Nm Ns )
 can lower it.
 The security levels are:
 .Bl -tag -width flag

On Tue, 5 Sep 2000, Sheldon Hearn wrote:

> On Tue, 05 Sep 2000 06:07:23 +1100, Bruce Evans wrote:
> 
> > Some more updates are needed.
> 
> As far as this PR is concerned, about the best improvement I can think
> of for the securelevel misunderstanding is included below.  I don't
> think that the manual page is lacking right now, but this patch causes
> it to state the situation explicitly.

I meant something like the following:

---
diff -c2 init.8~ init.8
*** init.8~	Thu Sep  7 01:04:21 2000
--- init.8	Thu Sep  7 01:06:54 2000
***************
*** 135,147 ****
  .El
  .Pp
! If the security level is initially -1, then
  .Nm
  leaves it unchanged.
  Otherwise,
  .Nm
! arranges to run the system in level 0 mode while single-user
! and in level 1 mode while multi-user.
! If level 2 mode is desired while running multi-user,
! it can be set while single-user, e.g., in the startup script
  .Pa /etc/rc ,
  using
--- 135,149 ----
  .El
  .Pp
! If the security level is initially nonzero, then
  .Nm
  leaves it unchanged.
  Otherwise,
  .Nm
! raises the level to 1 before going multi-user for the first time.
! No process can reduce the level, so it will be at least 1 for
! subsequent operation, even on return to single-user.
! If a level higher than 1 is desired while running multi-user,
! it can be set while single-user for the first time,
! e.g., in the startup script
  .Pa /etc/rc ,
  using
---

Init no longer even attempts to lower the level, and the example of
switching to level 2 rotted when we implemented level 3.

Please improve my wording if possible.

Bruce

Comment 10 Sheldon Hearn 2000-09-12 13:31:39 UTC

State Changed
From-To: open->closed

Handling of securelevels clarified in rev 1.23 of init.8. 

Comment 11 Sheldon Hearn 2000-09-12 13:31:39 UTC

Responsible Changed
From-To: freebsd-bugs->sheldonh

I committed something very close to Bruce's patchy.