Bug 25447

Comment 1 nik 2001-02-28 22:53:58 UTC

On Tue, Feb 27, 2001 at 11:12:46PM -0800, dima@unixfreak.org wrote:
> 
> >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
-- 
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

> 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>

Comment 3 dd 2001-03-11 21:58:52 UTC

Responsible Changed
From-To: freebsd-doc->dd

My PR.

Comment 4 dd 2001-03-13 01:26:41 UTC

State Changed
From-To: open->closed

Patch committed.