From owner-freebsd-doc Thu Mar 1 20:40:11 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 8F73637B718 for ; Thu, 1 Mar 2001 20:40:03 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.1/8.11.1) id f224e3752509; Thu, 1 Mar 2001 20:40:03 -0800 (PST) (envelope-from gnats) Date: Thu, 1 Mar 2001 20:40:03 -0800 (PST) Message-Id: <200103020440.f224e3752509@freefall.freebsd.org> To: freebsd-doc@freebsd.org Cc: From: Dima Dorfman Subject: Re: docs/25447: [PATCH] New FAQ entry about inability to unset schg flag Reply-To: Dima Dorfman Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR docs/25447; it has been noted by GNATS. From: Dima Dorfman To: Nik Clayton Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: docs/25447: [PATCH] New FAQ entry about inability to unset schg flag Date: Thu, 01 Mar 2001 20:31:55 -0800 > I'm horrendously lazy. Could you split this in to two questions, with > the bulk of the copy going in to a "What are securelevels?" question? Good idea. Attached is the patch. I expanded on the securelevel description quite a bit in hopes of answering as many questions as possible; as always, references to the man pages are still there. Thanks Dima Dorfman dima@unixfreak.org P.S. The / thing is still broken (no ": "), and it doesn't look like nwlash is going to fix it any time soon (well, 1.62 is on his web site, and I don't see any mention of this in the change logs; perhaps I missed it?). If you want, I'll send a patch to freebsd.dsl to redefine the en-label-title-sep alist. P.P.S. Could you please look at PR docs/24888? It's a straight-forward FAQ entry that's been sitting there for almost a month. Thanks. 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/03/02 04:23:02 @@ -6559,6 +6559,100 @@ + + What is securelevel? + + + + 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., + root) is allowed to do them. At the time + of this writing, the securelevel mechanism is capable of, among + other things, limiting the ability to, + + + + unset certain file flags, such as + schg (the system immutable flag), + + + + write to kernel memory via + /dev/mem and + /dev/kmem, + + + + load kernel modules, and + + + + alter &man.ipfirewall.4; rules. + + + + To check the status of the securelevel on a running system, + simply execute the following command: + + &prompt.root; sysctl kern.securelevel + + The output will contain the name of the &man.sysctl.8; + variable (in this case, kern.securelevel) + 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. + + 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 installworld or changing the date), + you will have to change the securelevel setting in + /etc/rc.conf (you want to look for the + kern_securelevel and + kern_securelevel_enable variables) and + reboot. + + For more information on securelevel and the specific things + all the levels do, please consult the &man.init.8; manual + page. + + + + Securelevel is not a silver bullet; it has many known + deficiencies. More often than not, it provides a false + sense of security. + + 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 with 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. + + This point and others are often discussed on the + mailing lists, particuarly freebsd-security. Please search + the archives here 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. + + Consider yourself warned. + + + + + + How do I let ordinary users mount floppies, CDROMs and other removable media? @@ -6834,6 +6928,20 @@ address space on an IA32, or exactly 256MB. + + + + Why can't I unset the schg file + flag? + + + + You're running at an elevated (i.e., greater than 0) + securelevel. Lower the securelevel and try again. For more + information, see the FAQ entry on + securelevel and the &man.init.8; manual page. + + To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message