Date: Fri, 2 Nov 2001 00:08:19 -0600 From: Mike Meyer <mwm@mired.org> To: "Anthony Atkielski" <anthony@atkielski.com> Cc: "FreeBSD Questions" <freebsd-questions@freebsd.org> Subject: Re: Re[2]: Tiny starter configuration for FreeBSD Message-ID: <15330.14419.809266.281360@guru.mired.org> In-Reply-To: <002b01c1635f$5a5f4300$0a00000a@atkielski.com> References: <15330.6606.417524.41024@guru.mired.org> <002b01c1635f$5a5f4300$0a00000a@atkielski.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Anthony Atkielski <anthony@atkielski.com> types: > Mike writes: > > Gimp. Xsane. Gkrellm. Applixware Office. Pretty > > much the same kinds of things that you run on > > a Windows box, only with different names. > Where's Gimp? That would be an interesting test of the SuperX server that I'm > evaluating. The Graphics Image Manipulation Program. Think Photoshop. It's in the ports collection of FreeBSD. > > At this point in time, I'd trust your typical Unix > > system over your typical Windows NT system for two > > reasons: 1) Unix has a long history of security > > testing in hostile environments. 2) One of the selling > > points of Windows NT is that you don't have to hire > > experts to administer it. > Both excellent points. I think (2) is more important than (1), though. Most > exploits against NT have been directed at applications that behave in an > insecure way (such as bugs in IIS), not at the OS. In fact, I don't recall > hearing of anyone ever compromising NT security itself, although there may be a > few exploits out there, in the early days perhaps. Of course, if you are > running a bug-laden IIS, then having airtight system security won't help much. I have seen complaints about NT's security in general, but won't bother to chase them down. I think we can both accept that no program is perfect. > > I'd expect the machine installed and secured by > > experts to be more secure, even if the security > > mechanisms on it are less flexible than those > > available on the system installed by untrained monkeys. > Well, there are experts, and there are experts. Some administrators know > everything about the OS, but care nothing about security, or don't understand > what is secure and what isn't--for example, some administrators think that being > able to look up someone's password is a good idea, and still do not see the > serious flaws in any such "feature" after repeated explanation (fortunately, > both NT and UNIX forbid this, but unfortunately, UNIX still allows unaudited > impersonation, which is very bad). Which *may be* very bad in your environment. It's also easy to fix. > > > [Unix security model is known to be "massively insecure"]. > > By who? > By anyone who needs a secure system. And "secure" in this context doesn't mean > simply secure in a vacuum, but still secure after being set up to do useful > things. That's obviously not true. I need a secure system, and Unix does the job just fine, thank you. BSD Unix, in particular, was developed in an environment where it was providing computing services to some of the brightest programming students in the country, and it needed to be secured against them. Actually, I was looking for references to published papers, preferably in reviewed journals. > Point taken. In practice, however, administrators tend to drift towards > "massively insecure" as they try to overcome "massively inadequate." > > For example, one change I made to my system was to allow root logins from remote > terminals. I'd prefer to limit remote logins to root to my other machine, which > is on the LAN, but I'm not aware of an option to force that, so I had to open > root logins to the world. Thus, in order to obtain needed functionality, I had > to compromise security far more than I would have liked. I typically don't allow root to login at all, but I'm a bit paranoid. Allowing root to have a remote login means it's unaudited access, which as you've pointed out is a bad idea. That's why it's off by default. > (BTW, if there is a way to restrict the ability to log in as root to remote > connections from certain IP addresses only, I'd appreciate knowing how to do > this.) I haven't used it myself, but if you're running -stable, try reading the login.access man page, which provides exactly the facilities you want. I'd still recommend not allowing root to log in remotely. > Another nice thing about Multics was that it could offload part of its terminal > communication to a separate communications processor, instead of taking an > interrupt for every key pressed by every user. I have read that Cray hated > putting UNIX on its supercomputers because of the need to interrupt the entire > machine for every keystroke. Cray initially even tweaked the telnet daemon to only do linemode to help with that. Once they had people using the thing interactively, it turned out that there wasn't a measurable difference in total throughput. They described it to me as the interactive usage being "in the cracks" of the real jobs. > > As far as I know, nobody ever implemented the > > complete design. > Which parts remained unimplemented? The thing that pops immediately to mind is the number of security rings. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Q: How do you make the gods laugh? A: Tell them your plans. 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?15330.14419.809266.281360>