Date: Sun, 24 Jun 2001 02:32:09 -0700 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Shannon Hendrix" <shannon@widomaker.com>, <FreeBSD-advocacy@FreeBSD.ORG> Subject: RE: Ask a question.. Thanks.. Message-ID: <004201c0fc90$8a3cbb60$1401a8c0@tedm.placo.com> In-Reply-To: <20010622101630.C32692@widomaker.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>-----Original Message----- >From: owner-freebsd-advocacy@FreeBSD.ORG >[mailto:owner-freebsd-advocacy@FreeBSD.ORG]On Behalf Of Shannon Hendrix > >> While it seems that compartmentalizing is more secure, the security >> of ANY box is only as good as the administrator in charge of it. >> There's an old saying KISS (Keep It Simple Stupid) and I would be >> real concerned about a box that had "security" customizations to >> the level you describe. It seems more like an auditing nightmare. > >It's nothing new, and it's not an auditing nightmare, at least not any >more than any system of it's kind is. It's a lot like Multics was. You >have a system where you are protected even from root. Files cannot be >given to people whose security level is lower than the file, even by a >user with high security privs. root cannot read your private email >or files, only do their admin work. Mandatory access is useful in a >wide range of systems. > 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. Just remember, though that people all jumped onto the UNIX bandwagon precisely to _get away_ from the multi-layering of systems like Multics. They didn't call it "Mutt-Licks" for nothing, you know. >Anyway, their goal is a system that supports security and access control >like some other systems have (Multics), not to patch up every utility >program out there. > In short, to throw computing back 30 years. 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 intricate and have so many rules that if the admin leaves you just may as well reformat and start over because your never going to untangle the mess otherwise. There's an extreme usefulness in the UNIX system of having a single user account that can cut any gordion knot if need be. >Think about ISPs running systems like this, where your email is really >yours, and even their admins cannot read it. Their role could be defined >as delete only since obviously they need to be able to get rid of >accounts. But they need never be able to actually read your files. Just >an example. > 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 features like this are useful for general use UNIX systems >myself. It's definitely not for every server out there, but there have >been a lot of times when I could have used things like this. > Your example of internal control is useful to illustrate the point, but it's getting away from the topic of protecting from attackers and into the topic of "how best to administer a UNIX system" 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. That's a rather defeatist argument to me, and it almost seems to encourage sloppy programming - it's like "so what our crappy code is full of security 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. Anyway, all of this internal control horse pucky is a mirage for security anyway. So you have a convoluted internal control sytem that prevents root from reading people's mail. So what? All your doing is giving the cracker another target - now it's the internal control system. If your going to assume that he can make it onto the system eventually, then to be consistent then you have to assume that the internal control system itself is capabable of having security breaches. So, the cracker makes it onto the system, then sets about cracking the NSA add-ons, cracks them, and your system is just as hosed as the other guy's system that didn't have the NSA add-ons. 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 discovered. After all, a hole that exists in a UNIX or other system that only ONE person in the entire world knows about is not really a security problem, because that one person could never crack even 1% of all systems on the Internet if he spent the rest of his life cracking systems one after another. It only becomes a security problem when the cracking community starts disseminating the information - and since the good guys are perfectly able to read the same crack websites and mailing lists as the bad guys, one word gets out patches are released and the hole is no longer of any value. 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?004201c0fc90$8a3cbb60$1401a8c0>