From dima@unixfreak.org  Tue Feb 27 23:12:48 2001
Return-Path: <dima@unixfreak.org>
Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138])
	by hub.freebsd.org (Postfix) with ESMTP id C903537B719
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 27 Feb 2001 23:12:47 -0800 (PST)
	(envelope-from dima@unixfreak.org)
Received: from hornet.unixfreak.org (hornet [63.198.170.140])
	by bazooka.unixfreak.org (Postfix) with ESMTP id 59D5A3E0C
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 27 Feb 2001 23:12:47 -0800 (PST)
Received: (from dima@localhost)
	by hornet.unixfreak.org (8.11.1/8.11.1) id f1S7Ckr29108;
	Tue, 27 Feb 2001 23:12:46 -0800 (PST)
	(envelope-from dima)
Message-Id: <200102280712.f1S7Ckr29108@hornet.unixfreak.org>
Date: Tue, 27 Feb 2001 23:12:46 -0800 (PST)
From: dima@unixfreak.org
Reply-To: dima@unixfreak.org
To: FreeBSD-gnats-submit@freebsd.org
Subject: [PATCH] New FAQ entry about inability to unset schg flag
X-Send-Pr-Version: 3.2

>Number:         25447
>Category:       docs
>Synopsis:       [PATCH] New FAQ entry about inability to unset schg flag
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    dd
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Tue Feb 27 23:20:01 PST 2001
>Closed-Date:    Mon Mar 12 17:26:41 PST 2001
>Last-Modified:  Mon Mar 12 17:26:59 PST 2001
>Originator:     Dima Dorfman
>Release:        FreeBSD 4.2-20010102-STABLE i386
>Organization:
Private
>Environment:

Not relevant.

>Description:

The schg (system immutable) flag can't be unset when the securelevel
is above 0.  A lot of people seem to set securelevel without knowing
its implications, then send queries to -questions, and sometimes
-stable, asking why they can't unset the schg flag.  Amazingly enough,
this doesn't appear to already be in the FAQ; from a quick grep it
looks like it might be mentioned in the handbook, but if it is, it
isn't obvious.

The root of the problem is actually sysinstall's failure to notify the
user of the implications of securelevel.  I saw a thread about this
about a week ago, and it looks like progress was made, but if there
was a commit about it, I must've missed it.  In either case, these
questions aren't likely to cease any time soon.

>How-To-Repeat:

Read -questions.

>Fix:

Apply the following to doc/en_US.ISO_8859-1/books/faq/book.sgml.

Index: book.sgml
===================================================================
RCS file: /st/src/FreeBSD/doc/en_US.ISO_8859-1/books/faq/book.sgml,v
retrieving revision 1.146
diff -u -r1.146 book.sgml
--- book.sgml	2001/02/26 21:51:48	1.146
+++ book.sgml	2001/02/28 07:06:09
@@ -6834,6 +6834,59 @@
             address space on an IA32, or exactly 256MB.</para>
         </answer>
       </qandaentry>
+
+      <qandaentry>
+        <question>
+          <para>Why can't I unset the <literal>schg</literal> flag?  I
+            thought <username>root</username> was only constrained by
+            hardware limitations!</para>
+        </question>
+
+        <answer>
+          <para>Short answer: you're running at a securelevel > 0.  Lower
+            the securelevel and try again.  For more information, see the
+            &man.init.8; manual page.</para>
+
+          <para>Long answer: The operating system didn't used to limit
+            <username>root</username>; then the Internet changed from being
+            a research network to part-time home of some unfriendly people,
+            and security became a great concern.  One of the mechanisms of
+            trying to enforce security is the securelevel.  Securelevel
+            makes certain actions prohibited, even to
+            <username>root</username>.  One of these actions is the ability
+            to unset the <literal>schg</literal>, or system immutable,
+            flag.</para>
+
+          <para>This is a feature of securelevel.  The idea is to be able
+            to assert certain system-critical files' (e.g., the kernel,
+            &man.init.8;) integrity.  While the <literal>schg</literal>
+            flag is set, the kernel will not let anyone remove or modify
+            the file.  If the securelevel is set to something greater than
+            0, the kernel will also prohibit everyone from unsetting the
+            <literal>schg</literal> flag.</para>
+
+          <para>
+            <note>
+              <para>It should also be mentioned that while the idea of
+                securelevel and files that can't be modified sounds good in
+                theory, it rarely helps in practice against all but the
+                dumbest of attackers.  Securelevel, and hence the
+                protections of <literal>schg</literal>, can be easily
+                circumvented, by, e.g., rebooting the system.  Unless all
+                files used during the boot process are protected, the
+                attacker can possibly insert malicious code into them; and
+                if they are protected, administration is made almost
+                impossible without going to single-user mode.</para>
+
+              <para>The above is but one example of the deficiencies of
+                securelevel; consider yourself warned.</para>
+            </note>
+          </para>
+
+          <para>For more information on securelevel, please see the
+            &man.init.8; manual page.</para>
+        </answer>
+      </qandaentry>
     </qandaset>
   </chapter>
 
>Release-Note:
>Audit-Trail:

From: Nik Clayton <nik@freebsd.org>
To: dima@unixfreak.org
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: docs/25447: [PATCH] New FAQ entry about inability to unset schg flag
Date: Wed, 28 Feb 2001 22:53:58 +0000

 --C7zPtVaVf+AK4Oqc
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Tue, Feb 27, 2001 at 11:12:46PM -0800, dima@unixfreak.org wrote:
 >=20
 > >Number:         25447
 > >Category:       docs
 > >Synopsis:       [PATCH] New FAQ entry about inability to unset schg flag
 
 I'm horrendously lazy.  Could you split this in to two questions, with
 the bulk of the copy going in to a "What are securelevels?" question?
 
 Thanks.
 
 N
 --=20
 Internet connection, $19.95 a month.  Computer, $799.95.  Modem, $149.95.
 Telephone line, $24.95 a month.  Software, free.  USENET transmission,
 hundreds if not thousands of dollars.  Thinking before posting, priceless.
 Somethings in life you can't buy.  For everything else, there's MasterCard.
   -- Graham Reed, in the Scary Devil Monastery
 
 --C7zPtVaVf+AK4Oqc
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.0.4 (FreeBSD)
 Comment: For info see http://www.gnupg.org
 
 iEYEARECAAYFAjqdgYMACgkQk6gHZCw343UzQACeJSFLk6S9V+RinIJsRHrOmi6H
 EQkAnA6ABB3u4uxDj0k1yHEZFWgqMEVZ
 =o1JR
 -----END PGP SIGNATURE-----
 
 --C7zPtVaVf+AK4Oqc--

From: Dima Dorfman <dima@unixfreak.org>
To: Nik Clayton <nik@freebsd.org>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: docs/25447: [PATCH] New FAQ entry about inability to unset schg flag 
Date: Thu, 01 Mar 2001 20:31:55 -0800

 > I'm horrendously lazy.  Could you split this in to two questions, with
 > the bulk of the copy going in to a "What are securelevels?" question?
 
 Good idea.  Attached is the patch.  I expanded on the securelevel
 description quite a bit in hopes of answering as many questions as
 possible; as always, references to the man pages are still there.
 
 Thanks
 
 					Dima Dorfman
 					dima@unixfreak.org
 
 P.S.  The <warning>/<caution> thing is still broken (no ": "), and it
 doesn't look like nwlash is going to fix it any time soon (well, 1.62
 is on his web site, and I don't see any mention of this in the change
 logs; perhaps I missed it?).  If you want, I'll send a patch to
 freebsd.dsl to redefine the en-label-title-sep alist.
 
 P.P.S.  Could you please look at PR docs/24888?  It's a
 straight-forward FAQ entry that's been sitting there for almost a
 month.  Thanks.
 
 Index: book.sgml
 ===================================================================
 RCS file: /st/src/FreeBSD/doc/en_US.ISO_8859-1/books/faq/book.sgml,v
 retrieving revision 1.146
 diff -u -r1.146 book.sgml
 --- book.sgml	2001/02/26 21:51:48	1.146
 +++ book.sgml	2001/03/02 04:23:02
 @@ -6559,6 +6559,100 @@
        </qandaentry>
  
        <qandaentry>
 +        <question id="securelevel">
 +          <para>What is securelevel?</para>
 +        </question>
 +
 +        <answer>
 +          <para>The securelevel is a security mechanism implemented in the
 +            kernel.  Basically, when the securelevel is positive, the
 +            kernel restricts certain tasks; not even the superuser (i.e.,
 +            <username>root</username>) is allowed to do them.  At the time
 +            of this writing, the securelevel mechanism is capable of, among
 +            other things, limiting the ability to,</para>
 +
 +          <itemizedlist>
 +            <listitem>
 +              <para>unset certain file flags, such as
 +                <literal>schg</literal> (the system immutable flag),</para>
 +            </listitem>
 +
 +            <listitem>
 +              <para>write to kernel memory via
 +                <filename>/dev/mem</filename> and
 +                <filename>/dev/kmem</filename>,</para>
 +            </listitem>
 +
 +            <listitem>
 +              <para>load kernel modules, and</para>
 +            </listitem>
 +
 +            <listitem>
 +              <para>alter &man.ipfirewall.4; rules.</para>
 +            </listitem>
 +          </itemizedlist>
 +
 +          <para>To check the status of the securelevel on a running system,
 +            simply execute the following command:</para>
 +
 +          <screen>&prompt.root; <userinput>sysctl kern.securelevel</userinput></screen>
 +
 +          <para>The output will contain the name of the &man.sysctl.8;
 +            variable (in this case, <varname>kern.securelevel</varname>)
 +            and a number.  The latter is the current value of the
 +            securelevel.  If it is positive (i.e., greater than 0), at
 +            least some of the securelevel's protections are enabled.</para>
 +
 +          <para>You cannot lower the securelevel of a running system; being
 +            able to do that would defeat its purpose.  If you need to do a
 +            task that requires that the securelevel be non-positive (e.g.,
 +            an <maketarget>installworld</maketarget> or changing the date),
 +            you will have to change the securelevel setting in
 +            <filename>/etc/rc.conf</filename> (you want to look for the
 +            <varname>kern_securelevel</varname> and
 +            <varname>kern_securelevel_enable</varname> variables) and
 +            reboot.</para>
 +
 +          <para>For more information on securelevel and the specific things
 +            all the levels do, please consult the &man.init.8; manual
 +            page.</para>
 +
 +          <para>
 +            <warning>
 +              <para>Securelevel is not a silver bullet; it has many known
 +                deficiencies.  More often than not, it provides a false
 +                sense of security.</para>
 +
 +              <para>One of its biggest problems is that in order for it to
 +                be at all effective, all files used in the boot process up
 +                until the securelevel is set must be protected.  If an
 +                attacker can get the system to execute their code prior to
 +                the securelevel being set (which happens quite late in the
 +                boot process since some things the system must do at
 +                start-up cannot be done with an elevated securelevel), its
 +                protections are invalidated.  While this task of protecting
 +                all files used in the boot process is not technically
 +                impossible, if it is achieved, system maintenance will
 +                become a nightmare since one would have to take the system
 +                down, at least to single-user mode, to modify a
 +                configuration file.</para>
 +
 +              <para>This point and others are often discussed on the
 +                mailing lists, particuarly freebsd-security.  Please search
 +                the archives <ulink
 +                url="http://www.FreeBSD.org/search/">here</ulink> for an
 +                extensive discussion.  Some people are hopeful that
 +                securelevel will soon go away in favor of a more
 +                fine-grained mechanism, but things are still hazy in this
 +                respect.</para>
 +
 +              <para>Consider yourself warned.</para>
 +            </warning>
 +          </para>
 +        </answer>
 +      </qandaentry>
 +
 +      <qandaentry>
          <question id="user-floppymount">
            <para>How do I let ordinary users mount floppies, CDROMs and other removable
              media?</para>
 @@ -6834,6 +6928,20 @@
              address space on an IA32, or exactly 256MB.</para>
          </answer>
        </qandaentry>
 +
 +      <qandaentry>
 +        <question id="unsetting-schg">
 +          <para>Why can't I unset the <literal>schg</literal> file
 +            flag?</para>
 +        </question>
 +
 +        <answer>
 +          <para>You're running at an elevated (i.e., greater than 0)
 +            securelevel.  Lower the securelevel and try again.  For more
 +            information, see <link linkend="securelevel">the FAQ entry on
 +            securelevel</link> and the &man.init.8; manual page.</para>
 +        </answer>
 +      </qandaentry>
      </qandaset>
    </chapter>
  
Responsible-Changed-From-To: freebsd-doc->dd 
Responsible-Changed-By: dd 
Responsible-Changed-When: Sun Mar 11 13:58:52 PST 2001 
Responsible-Changed-Why:  
My PR. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=25447 
State-Changed-From-To: open->closed 
State-Changed-By: dd 
State-Changed-When: Mon Mar 12 17:26:41 PST 2001 
State-Changed-Why:  
Patch committed. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=25447 
>Unformatted:
