From owner-freebsd-questions Wed Dec 9 08:50:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA01528 for freebsd-questions-outgoing; Wed, 9 Dec 1998 08:50:25 -0800 (PST) (envelope-from owner-freebsd-questions@FreeBSD.ORG) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA01523 for ; Wed, 9 Dec 1998 08:50:24 -0800 (PST) (envelope-from mikebo@Mars.mcs.net) Received: from Mars.mcs.net (mikebo@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id KAA12394; Wed, 9 Dec 1998 10:50:17 -0600 (CST) Received: (from mikebo@localhost) by Mars.mcs.net (8.8.7/8.8.2) id KAA03339; Wed, 9 Dec 1998 10:50:16 -0600 (CST) From: Michael Borowiec Message-Id: <199812091650.KAA03339@Mars.mcs.net> Subject: Re: Securing the FreeBSD console To: gsutter@pobox.com (Gregory Sutter) Date: Wed, 9 Dec 1998 10:50:07 -0600 (CST) Cc: questions@FreeBSD.ORG In-Reply-To: <19981208232740.B4021@orcrist.mediacity.com> from "Gregory Sutter" at Dec 8, 98 11:27:40 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg, et al. - Thanks for writing with solutions! > > > To prevent rebooting your server with a Ctrl-Alt-Del requires > > a kernel config change. Where is this documented? > > In the LINT file, /sys/i386/conf/LINT, under the syscons section, you > can see options SC_DISABLE_REBOOT. > Done. Thanks! > > Xlock is useless with the sc0 console driver, since typing Ctrl-Alt-F1 > > breaks out of graphics mode, back to the virtual terminal. Then one simply > > does a Ctrl-C and they're in... How can this be disabled? > > Brand new versions of xlock have an option, vtlock, which disables vt > switching. You'll need to be running at least xlockmore-4.12 to get > this option -- 4.11 doesn't have it. > Doh! I tried installing this, but 4.12 is having problems running. It's complaining about not finding a Mesa shared library, even though I installed this Mesa package. Hmmm.... Thanks for the technical help... Now on to the philosophical. > > Anyone know why FreeBSD ships with all these security holes enabled by > > default? I checked the FreeBSD Security web page, and there was no mention > > of any of these "features", or how to plug them. (Did I miss something?) > > Sure. They're not security holes on most systems. If you want to > disable three-finger saluting from the console, that's your business. If > you want to disable vt switching while in xlock, that's your business > too. If you want to disable ctrl-alt-backspace to kill X, that as well > is your own business. Most people _do_ find them features, not security > holes. > Well, locks exist to keep honest people honest. They are not meant to thwart a determined attack. But by any reasonable definition, these sure the heck ARE security holes, and should be documented in BIG LETTERS right in the installation notes. I can appreciate that many people run their BSD systems at home, or in otherwise secure environments, and that these escapes provide an easy back-door when things don't go quite right. However, since FreeBSD is being touted as a server OS, I don't think it's unreasonable to default to more secure behavior and let the hobbyist take action to defeat the security if it isn't required. IMO, that's a lot better than saying NOTHING in the release notes, OR the online security web page - implying that xlock can be expected to work as advertised, without first plugging a half-dozen one-second exploits scattered throughout the system. Just FYI... I'm introducing FreeBSD at work, a 1000-seat engineering environment, where people share offices and labs that don't lock. Most of the UNIX folk in my environment were horrified by these defaults - but moreso by the lack of documentation pointing them out. It was even suggested the OS not be used at all, for fear that (1) the FreeBSD team either doesn't understand, or doesn't take commercial security concerns seriously, and (2) that there are probably many more undocumented actions in a "hobbyist (read TOY) OS" that could be exploited to gain fast access. I happen to disagree with these assertions, but they won't make my job as "FreeBSD in the Enterprise Advocate" any easier. Regards, - Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message