Date: Wed, 9 Dec 1998 10:50:07 -0600 (CST) From: Michael Borowiec <mikebo@Mcs.Net> To: gsutter@pobox.com (Gregory Sutter) Cc: questions@FreeBSD.ORG Subject: Re: Securing the FreeBSD console Message-ID: <199812091650.KAA03339@Mars.mcs.net> In-Reply-To: <19981208232740.B4021@orcrist.mediacity.com> from "Gregory Sutter" at Dec 8, 98 11:27:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812091650.KAA03339>