Date: Sun, 6 Oct 1996 15:23:44 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Bruce Evans <bde@zeta.org.au> Cc: current@freebsd.org Subject: Re: secure level diffs to kern_mib.c, LINT Message-ID: <Pine.SV4.3.93.961006150625.6320A-100000@parkplace.cet.co.jp> In-Reply-To: <199610060456.OAA10795@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
What changes would be necessary to *guarantee* that the system increments securelevel to 1, *before* any deamons are started? Putting it in rc.local assumes that the securelevel's definition of multi-user mode will never be made more precise. I'm less concerned with putting securelevel=2 in rc, because this is just locking another deadbolt and isn't as critical as the transition from 0 to 1. On Sun, 6 Oct 1996, Bruce Evans wrote: > >FreeBSD defaults securelevel to -1, use the following diffs if you prefer > >normal bsd operations or want a choice. Man init(8) for details. > > Use `sysctl -w kern.securelevel=0' in /etc/rc.local if you want the > BSD4.4Lite default. If you want the securelevels > 0 to actually work, At least it's an easy start for the /kernel case. > then you must do considerably more to fix security holes in certain > device drivers. If you want securelevels > 0 to be useful, then you > must do considerably more to make all critical system directories and > log files immutable or append-only, and be prepared to check and restore > all files on the system which aren't immutable if the log files show > that there may have been a breakin. > > >systm.h also has securelevel related comments. The note about securelevel > >initialization in .bss is controversial, please draw your own conclusions. > No, the part about the bss is just bogus. I removed that part and rewrote > the rest of the comment to avoid documenting (previous) policy in systm.h. I see it as a small speed bump and I'll take anything in my favor. On the otherhand taking it away outright on grounds that the kernel can be patched elsewhere is questionable. Regards, Mike Hancock > Bruce > > diff -c2 systm.h~ systm.h > *** systm.h~ Tue Oct 1 04:47:17 1996 > --- systm.h Sun Sep 15 07:33:36 1996 > *************** > *** 61,74 **** > * newfs while the system is secured. > * > ! * In normal operation, the system runs in level 0 mode while single user > ! * and in level 1 mode while multiuser. If level 2 mode is desired while > ! * running multiuser, it can be set in the multiuser startup script > ! * (/etc/rc.local) using sysctl(1). If it is desired to run the system > ! * in level 0 mode while multiuser, initialize the variable securelevel > ! * in /sys/kern/kern_sysctl.c to -1. Note that it is NOT initialized to > ! * zero as that would allow the kernel binary to be patched to -1. > ! * Without initialization, securelevel loads in the BSS area which only > ! * comes into existence when the kernel is loaded and hence cannot be > ! * patched by a stalking hacker. > */ > extern int securelevel; /* system security level */ > --- 61,71 ---- > * newfs while the system is secured. > * > ! * 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. > */ > extern int securelevel; /* system security level */ >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.93.961006150625.6320A-100000>