From owner-freebsd-doc Tue Feb 27 23:20: 8 2001 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 89E2437B71C for ; Tue, 27 Feb 2001 23:20:01 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f1S7K1i46766; Tue, 27 Feb 2001 23:20:01 -0800 (PST) (envelope-from gnats) Received: from bazooka.unixfreak.org (bazooka.unixfreak.org [63.198.170.138]) by hub.freebsd.org (Postfix) with ESMTP id C903537B719 for ; Tue, 27 Feb 2001 23:12:47 -0800 (PST) (envelope-from dima@unixfreak.org) Received: from hornet.unixfreak.org (hornet [63.198.170.140]) by bazooka.unixfreak.org (Postfix) with ESMTP id 59D5A3E0C for ; Tue, 27 Feb 2001 23:12:47 -0800 (PST) Received: (from dima@localhost) by hornet.unixfreak.org (8.11.1/8.11.1) id f1S7Ckr29108; Tue, 27 Feb 2001 23:12:46 -0800 (PST) (envelope-from dima) Message-Id: <200102280712.f1S7Ckr29108@hornet.unixfreak.org> Date: Tue, 27 Feb 2001 23:12:46 -0800 (PST) From: dima@unixfreak.org Reply-To: dima@unixfreak.org To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: docs/25447: [PATCH] New FAQ entry about inability to unset schg flag Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >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. + + + + Why can't I unset the schg flag? I + thought root was only constrained by + hardware limitations! + + + + 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. + + Long answer: The operating system didn't used to limit + root; 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 + root. One of these actions is the ability + to unset the schg, or system immutable, + flag. + + 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 schg + 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 + schg flag. + + + + 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 schg, 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. + + The above is but one example of the deficiencies of + securelevel; consider yourself warned. + + + + For more information on securelevel, please see the + &man.init.8; manual page. + + >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message