Date: Tue, 27 Feb 2001 23:12:46 -0800 (PST) From: dima@unixfreak.org To: FreeBSD-gnats-submit@freebsd.org Subject: docs/25447: [PATCH] New FAQ entry about inability to unset schg flag Message-ID: <200102280712.f1S7Ckr29108@hornet.unixfreak.org>
next in thread | raw e-mail | index | archive | help
>Number: 25447
>Category: docs
>Synopsis: [PATCH] New FAQ entry about inability to unset schg flag
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-doc
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Tue Feb 27 23:20:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator: Dima Dorfman
>Release: FreeBSD 4.2-20010102-STABLE i386
>Organization:
Private
>Environment:
Not relevant.
>Description:
The schg (system immutable) flag can't be unset when the securelevel
is above 0. A lot of people seem to set securelevel without knowing
its implications, then send queries to -questions, and sometimes
-stable, asking why they can't unset the schg flag. Amazingly enough,
this doesn't appear to already be in the FAQ; from a quick grep it
looks like it might be mentioned in the handbook, but if it is, it
isn't obvious.
The root of the problem is actually sysinstall's failure to notify the
user of the implications of securelevel. I saw a thread about this
about a week ago, and it looks like progress was made, but if there
was a commit about it, I must've missed it. In either case, these
questions aren't likely to cease any time soon.
>How-To-Repeat:
Read -questions.
>Fix:
Apply the following to doc/en_US.ISO_8859-1/books/faq/book.sgml.
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>
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-doc" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102280712.f1S7Ckr29108>