Attachment 13340 Details for Bug 25447 – file.diff

[patch] file.diff

file.diff (text/plain), 3.03 KB, created by dima on 2001-02-28 07:20:01 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: dima

Created: 2001-02-28 07:20:01 UTC

Size: 3.03 KB

patch

obsolete

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

Actions: View | Diff

Attachments on bug 25447: 13340