Date: Thu, 1 Mar 2001 20:40:03 -0800 (PST) From: Dima Dorfman <dima@unixfreak.org> To: freebsd-doc@freebsd.org Subject: Re: docs/25447: [PATCH] New FAQ entry about inability to unset schg flag Message-ID: <200103020440.f224e3752509@freefall.freebsd.org>
index | next in thread | raw e-mail
The following reply was made to PR docs/25447; it has been noted by GNATS.
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>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103020440.f224e3752509>