Date: Wed, 27 Jun 2001 00:37:33 -0400 From: Shannon <shannon@widomaker.com> To: Ted Mittelstaedt <tedm@toybox.placo.com> Cc: freebsd-advocacy@freebsd.org Subject: Re: Ask a question.. Thanks.. Message-ID: <20010627003733.B27564@widomaker.com> In-Reply-To: <004201c0fc90$8a3cbb60$1401a8c0@tedm.placo.com>; from tedm@toybox.placo.com on Sun, Jun 24, 2001 at 02:32:09AM -0700 References: <20010622101630.C32692@widomaker.com> <004201c0fc90$8a3cbb60$1401a8c0@tedm.placo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jun 24, 2001 at 02:32:09AM -0700, Ted Mittelstaedt wrote: > Yes, I understand that kind of thinking, it's useful for military or > medical or high-security government systems where a single mistake can > kill people. Things like mandatory access controls are also useful in banking and customer database applications, just to name two I've been involved in recently. > 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. > In short, to throw computing back 30 years. I don't see it that way. I'm not suggesting everything in Trusted BSD or SELInux (insert trusted system name here) should be made mainstream, and I don't see how you get the idea it will have this particular negative effect. The UNIX security model is nearly 25 years old BTW... are we throwing ourselves back by using it? > OK, maybe I'm too harsh, but along with all this goodness comes a lot of > ugliness of putting systems into place that can allow admins that have > really screwey ideas to create monstrosities of systems that are so Exactly how does UNIX right now prevent admins from doing this? I don't believe you should limit technology to that which does the least damage in the hands of a moron. > There's an extreme usefulness in the UNIX system of having a single user > account that can cut any gordion knot if need be. How do the new features being added or suggested for FreeBSD prevent this? For that matter, how was a Multics operator prevented from handling this? 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. My main workstation has access control lists and file flags, but they aren't being used, so they do no harm by being there. > I think that your not giving any credibility to the existing UNIX > permissions systems. Is there any reason that all your ISP admins > _need_ to have root access? What about creating groups and putting > permission bits on files and controlling it that way? Too boring? I think you assume too much: I agree with you. In the absence of mandatory access control, I have used front-end programs to get data to users, in situations where I could not have them giving copies of that data to anyone else. 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. > 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. > That's a rather defeatist argument to me, and it almost seems to encourage > sloppy programming [snip] ...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. > holes, you can depend on this great internal access control a-la Multics > to keep them from doing anything" Your statement "...recommend _you_ > patch things like that..." even carries echos of this "security holes > are the end-user's problem, not the developer's" attitude. You got your attribution wrong, I didn't say that. I think security is ulimately everyone's problem, especially when it fails. > 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. > So you have a convoluted internal control sytem [snip] If the administration of the system is so bad that the internal controls are convoluted as you say, then the problem is the people. That's a constant for all systems. > There's a lot to be said for assuming that attackers making it inside > is abnormal - and taking steps to close holes as fast as they are 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, and as with all features, potential for abuse should not dictate its inclusion into a system. -- shannon@widomaker.com _________________________________________________ ______________________/ armchairrocketscientistgraffitiexenstentialist "And in billows of might swell the Saxons before her,-- Unite, oh unite! Or the billows burst o'er her!" -- Downfall of the Gael 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?20010627003733.B27564>