Date: Sat, 10 Aug 1996 14:54:58 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, jds@TracerTech.COM Cc: Hackers@freebsd.org, michaelh@cet.co.jp Subject: Re: kern_mib.c:int securelevel = -1; Message-ID: <199608100454.OAA16556@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>#ifdef SOAPBOX_MODE >Thus, the comment in the systm.h just gives a false sense of security to >anyone who reads it, puts securelevel in bss, and sits back feeling better >about it. ISTR pointing this out in old mail :-). This time, I deleted the bogus text (about the bss) and rewrote the text that doesn't match reality to the following: * If `securelevel' is initially 0, then process 1 normally arranges to run * the system in level 0 mode while single user and in level 1 mode while * multiuser. If `securelevel' is initially -1, then process 1 normally * leaves it unchanged, so that the system always runs in level 0 mode. In * both cases, if a more secure mode is desired, it can be set using * sysctl(8) in the multi-user startup script (/etc/rc.local) or earlier. * Process 1 will then reduce the level to 0 if single user mode is resumed. This is the wrong place to document the internals of init(8) and init.8 is probably the wrong place to document kern.securelevel. Currently, the big comment in systm.h is more or less duplicated in init.8 (except the part about the bss). There are stupid bugs in both - systm.h refers to sysctl(1) and says to patch `securelevel' in kern_sysctl.c (where it no longer lives) while init.8 says to patch `securelevel' in param.c (where it would now conflict with the default initialization). >The impression I've gotten is that securelevel was put in to play with >filesystem-level support for append-only and immutable files, rather than >as a concerted effort to really make BSD more secure. >IMHO. >#endif I think it's also to play with making BSD more secure. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608100454.OAA16556>