Date: Wed, 27 Jun 2001 01:41:10 -0700 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Shannon" <shannon@widomaker.com> Cc: <freebsd-advocacy@freebsd.org> Subject: RE: Ask a question.. Thanks.. Message-ID: <000801c0fee4$ea8bc140$1401a8c0@tedm.placo.com> In-Reply-To: <20010627003733.B27564@widomaker.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>-----Original Message----- >From: Shannon [mailto:shannon@widomaker.com] >Sent: Tuesday, June 26, 2001 9:38 PM >To: Ted Mittelstaedt >Cc: freebsd-advocacy@freebsd.org >Subject: Re: Ask a question.. Thanks.. > > >On Sun, Jun 24, 2001 at 02:32:09AM -0700, Ted Mittelstaedt wrote: > > >> Just remember, though that people all jumped onto the UNIX >> bandwagon precisely to _get away_ from the multi-layering of systems >> like Multics. > >No idea where you got that idea from. The majority of people who have >jumped on the UNIX bandwagon never even saw Multics. Many of them >probably don't even know what it is. > Back when UNIX was first being used in the Universities the students preferred it over VMS or other proprietary systems. This is well documented just read any detailed UNIX history. Granted there were a lot of other reasons than easier-to-deal-with security, but the ability to actually do things with a system without having to go running for the administrator every 5 minutes is a good thing to have. Of course, there's a place for everything. Obviously you wouldn't want this in a corporate environment like a bank where you have to maintain security to the nth level, but most corporate environments aren't like that. > >I don't believe you should limit technology to that which does the least >damage in the hands of a moron. > Perhaps for this, but would you want the most advanced technological developments in armaments posted for the world to view? Or would you want the government to permit television sets to be placed in automobiles in view of the driver? > >Keep in mind that a primary difference between these feature on Multics >and UNIX is that it should be largely transpartent in the latter if you >don't make use of the feature. > Tell that to the Kerberos people who made Kerberos installation the default for FreeBSD. It's definitely not transparent if you forget to uncheck the Kerberos libraries when your installing FreeBSD, from that point on you get lots of irritating messages about "unknown realm" and such when you login to the system. Yes, any new security features SHOULD be transparent to the user unless they deliberately turn them on - but it appears the history of FreeBSD is that when new security features are developed they are forced on people, and you have to deliberately turn them off. For example, MD5 passwords were forced, sshd was forced, Kerberos was forced, syslogd change of defaults was forced, etc. etc. etc. > >I'm sure you are aware of the fact that there are limits to what can be >done with groups and permission bits on file, and I don't see why we >should not address that. Some things I have done would have been much >easier if with better file access controls. > Oh I agree there are limits, but I think that most admins THINK they are being limited when in reality they just don't understand permission bits. How long did it take before we finally started getting people to put each user in it's own group? It's been said before but the permissions bits are coarse-grained access control, ACL's are fine-grained access control. Well fine-grained allows you to do a lot of things but if you use it then it's more complicated than coarse. In short for the additional functionality you do lose some simplicity. >> Getting back to the original topic, the "internal access control" >> argument in the context of a system that needs to be hardened to >> the outside predicates one thing - that your just assuming that the >> attackers _are_ going to get in. > >I don't think we should assume they will not. I think it is dangerous to >make that assumption. Therefore, I see internal security as another tool >to fight the same problem. > I'm not saying to assume that they won't get in, I'm just saying not to assume they will. Hair-splitting perhaps, but not really because what it means is what do you consider abnormal? I consider them getting in as completely abnormal and grounds to destroy the system and remake it from scratch. If your going to expect them to get in, it follows that when they do your not going to be as concerned with flushing the system. >...and that sounds irrational to me. In fact, assuming external security >is just as likely to encourage sloppy behavior. If people assume no one >will ever get through a firewall or a system's security, then they may >also decide there is therefore no need to secure their internal network. > Is there any evidence that assuming external security is weak will push people into securing their internal network? It seems to me that people eiter are going to secure their internal net or they won't, irregardless of external security. There's a fundamental issue with security that I'm sure your aware of - when internal security is intrusive people want to try to go around it, because they consider it a nuisance. In a bank, or military, or hospital, or whatever the administrators have a tremendous physological advantage to force users to jump through hoops to get at data. People will accept having to remember nine different passwords that get aged every month in a hospital because you can wave "patient confidentiality" around the moment they complain, and the rest of the users in the hospital will sit on the complainer. But, in a casual office environment you simply won't be able to enforce this because at some level people realize that every scrap of data on the planet is NOT of the same importance. ACL's may be really cool but they will go out the window the first time the Director of Marketing goes to the CEO and says "why can't we just have one area on the server that everybody can have the same full access to the marketing data, we trust people" > >I think security is ulimately everyone's problem, especially when it >fails. > Exactly. But this infers that it's not just the administrators problem, it's the users problem too. And most users I've met do not wish to complicate their own access to the data they work with and will work against you when you try to force them to secure their work. >> Anyway, all of this internal control horse pucky is a mirage for >> security anyway. > >Bah! It's useful at a system and a network level, and we have a lot >of historical evidence to prove it. The "impervious door" method of >security is foolish. > A network with an "impervious door" that the admin is paying attention to will be more secure than a "many little doors" network that the admin does not pay attention to. fine-grained access controls like your advocating have a lot of theoretical security advantages over coarse-grained like the "impervious door" method. But it's the maintainence and implementation that is what really determines which method is more effective. > >I don't disagree. But at the same time, I welcome changes to FreeBSD >that support more internal controls. You don't have to use it, see Kerberos treatment above... >and as >with all features, potential for abuse should not dictate its inclusion >into a system. > Frankly I don't know if there's anyone who can write a good criteria for including or not including anything in the base FreeBSD distribution. Some things are obvious - BIND for example - but your getting into a much greyer area with some of these security things. There's nothing wrong with making a feature optional - the ports directories are stuffed with numerous Good Programs that have tremendous reason for inclusion in the base distribution. For example Apache - it's probably used far more then Kerberos is, yet Kerberos is included by default and Apache isn't. Ted Mittelstaedt tedm@toybox.placo.com Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000801c0fee4$ea8bc140$1401a8c0>