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
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
|
|
@ -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>
|
||||
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue