Explain the securelevel mechanism, and use that explanation to explain

why it might not be possible to unset the schg file flag without
rebooting.

PR:		25447
Approved by:	nik
This commit is contained in:
Dima Dorfman 2001-03-13 01:26:08 +00:00
parent 00d8ee7114
commit 471a3a7965
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=8990
2 changed files with 218 additions and 2 deletions

View file

@ -11,7 +11,7 @@
<corpauthor>The FreeBSD Documentation Project</corpauthor>
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.151 2001/03/11 12:44:47 alex Exp $</pubdate>
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.152 2001/03/13 01:22:20 dd Exp $</pubdate>
<abstract>
<para>This is the FAQ for FreeBSD versions 2.X, 3.X, and 4.X.
@ -6574,6 +6574,100 @@ define(`confDELIVERY_MODE',`deferred')dnl</programlisting>
</answer>
</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 at 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
@ -6855,6 +6949,20 @@ define(`confDELIVERY_MODE',`deferred')dnl</programlisting>
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>

View file

@ -11,7 +11,7 @@
<corpauthor>The FreeBSD Documentation Project</corpauthor>
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.151 2001/03/11 12:44:47 alex Exp $</pubdate>
<pubdate>$FreeBSD: doc/en_US.ISO_8859-1/books/faq/book.sgml,v 1.152 2001/03/13 01:22:20 dd Exp $</pubdate>
<abstract>
<para>This is the FAQ for FreeBSD versions 2.X, 3.X, and 4.X.
@ -6574,6 +6574,100 @@ define(`confDELIVERY_MODE',`deferred')dnl</programlisting>
</answer>
</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 at 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
@ -6855,6 +6949,20 @@ define(`confDELIVERY_MODE',`deferred')dnl</programlisting>
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>