Date: Fri, 2 Nov 2001 06:29:27 +0100 From: "Anthony Atkielski" <anthony@atkielski.com> To: "Mike Meyer" <mwm@mired.org>, "FreeBSD Questions" <freebsd-questions@freebsd.org> Subject: Re: Re[2]: Tiny starter configuration for FreeBSD Message-ID: <002b01c1635f$5a5f4300$0a00000a@atkielski.com> References: <15330.6606.417524.41024@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Also, how many of you have bought the SuperX server (Frontier Technologies)? It is terribly expensive--buying it would increase the overall cost of my system by about 50%!--and I'm wondering why people are paying so much for it. > Having a minimal security mechanism - which is > how Thompson and Ritchie described the Unix > security mechanism - is *not* the same thing > as being insecure. True in theory, but often not true in practice. The more minimal the security provisions, the easier it is to forget to do things as they should be done, resulting in security compromises. I've never been a UNIX administrator until now, but I've worked as an administrator on other systems with virtually identical security models, and one must be extremely careful about maintaining security on them. > 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'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). > I don't know how NT's defaults are chosen, but MS's > historical choices have been for ease of use over > security, so I'd expect the NT defaults to be > insecure. Correct. The system is delivered secure out of the box, but the default options are such that it's very easy to undo this security as you configure and install things, unless you also watch security and set options to their more secure values as necessary. > 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. > And note that "massively inadequate" is *not* the same > thing as "massively insecure". 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. (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.) > Actually, the *design* of Multics was some of the > best ever done. I had some complaints about Multics--its phenomenal slowness being at the top of the list--but the security was amazing, and very appealing to paranoid administrators such as myself. 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. > As far as I know, nobody ever implemented the > complete design. Which parts remained unimplemented? > 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?002b01c1635f$5a5f4300$0a00000a>