Date: Thu, 1 Mar 2001 20:40:03 -0800 (PST) From: Dima Dorfman <dima@unixfreak.org> To: freebsd-doc@freebsd.org Subject: Re: docs/25447: [PATCH] New FAQ entry about inability to unset schg flag Message-ID: <200103020440.f224e3752509@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR docs/25447; it has been noted by GNATS. From: Dima Dorfman <dima@unixfreak.org> To: Nik Clayton <nik@freebsd.org> 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 <warning>/<caution> 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 @@ </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 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.</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 media?</para> @@ -6834,6 +6928,20 @@ 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> 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?200103020440.f224e3752509>