[mod: This discussion has been going on "offline" with an occasional CC to linux-security. By the time I got around to do another "moderation round" this one was the latest. Everyone is keeping good context, so I think you all will be able to follow the discussion. --REW]>>>>> <seifried@seifried.org> writes:>> The only thing I can see coming out of a "checklist" security setup >> is a false sense of security. The moment poor Joe User does >> something unanticipated or tricky, he'll be both unaware of his >> problem and unable to handle it once/if detected. Conversely, a >> clueful user stands a chance at anticipating problems and being >> able to handle them.> That is rather arrogant if you don't mind me saying so. Joe User > would be up shit creek in any case. If we follow this dogma that > teaching users is bad because they won't know enough to deal with > every eventuality, well where does one start? We should force users > to use Linux and learn it inside and out for a few months before > even letting them secure their system?This is not what I said. I merely point out that it is difficult or perhaps impossible to make a "checklist" that will be complete enough to result in a system that is actually secure. Particularly so over time. And note that while I don't think that your book will actually result in fully secure Linux systems run by neophytes, I do think it's a net improvement in the state of the world. The more material out there for people to learn from, the better...> Theory is great but most people do not have the time, or technical > background to read PUIS. To draw an analogy:> I have a car. I know how to drive it. I can change flat tires, add > oil and gas. This covers about 99% of normal stuff. I take it to a > car mechanic when it needs it. I am not going to stop on the side of > the road, pull 200 pounds of tools out of the trunk and change all > the gaskets in the engine.Absolutely. But network security is more complex than car maintenance. It also differs in that "99% secure" isn't significantly better than "40% secure". Anyone interested in breaking in has only to try out a bag of tricks until he hits that forgotten 1%. OTOH, a 99% well maintained car is very nearly indistinguishable from a 99.9% well maintained car.>> Linux isn't ready, any more than any other Unix, to be thought of >> as "secure" in an environment of cluelessness. Neither is any >> other operating system, although some probably fare much better out >> of the box...> That's the beauty of RedHat however. It's standardized. I tell you > to run pwconv and grpconv as root, and check the files in /etc and > boom, you got shadow passwords. You follow my instructions to chroot > and change the user dns runs as and boom, you got named running a > hell of lot more safely.Red Hat isn't any more standardized than Solaris, Digital UNIX, AIX, or any of the others. RH might even be less so - there are a lot of interchangable packages whereas most commercial UNIXes tend to have a fixed base and a pile of optional packages. In any case, more secure configurations like shadow passwords and chrooted bind are things which Red Hat should provide out of the box.>> Now, with all that said, I think the best thing would be to do >> something to raise awareness of the issues with the unaware folks >> out there. At least then they'll know that they're naked.> Guess what, most people do not want to really learn all the ins and > outs. they just want to secure the system. They usually learn in > time, but expecting them to sit down and study Linux manuals/etc is > a bit much.Hmm. An admin cannot secure something he does not understand. Expecting a Unix system to operate flawlessly without reading and understanding the instructions is clearly not the way to go. Shipping a Unix system that starts with no known misconfigurations is a good start, and it's what the best Linux vendors have been trying to do, albeit with limited success. Anything beyond that requires clue on the admin's part.> All the feedback I have gotten (except from you =)) has been very > positive, and mostly from semi clued in users saying they did X and > it worked and thank you.Leave it to me to ruin an otherwise sunny day ;) Remember, I'm allowed to be wrong. But it's more likely that we both are. Such is the nature of the human mind...> Making a person aware that their system is unsecure isn't really > going to help much, however giving them instructions on a variety of > simple to complicated things they can do to secure it from a > majority of attacks will help.Sure it will help - otherwise they'll never go find the instructions. My argument is simply that, since most of the instructions and tools already exist, we should just tell people why they need them and where to find them. This argument applies to Windows users even more - they're _all_ running around with their pants down. Sheesh!>> Do Red Hat, SuSE, or Debian manuals include a section on security? >> A brief introduction, with a discussion of just what RH does and >> doesn't do for you (ie, prompt updates, etc), would be a good thing >> to have included with each copy.> Not really. Talk to RedHat about that (I am not associated with > RedHat in any way other then being a customer).They're out there. But until I bother to actually look, they'll ignore me. So I looked, and the answer is basically no - there isn't a section on security in the RH 5.1 manual. There are occasional brief bits on certain security procedures like restricting a service with tcp_wrappers, and where to get ssh as an rpm, but little discussion of why you would want these things.> P.S. I personally think PUIS is a great book, but it's way to > advanced for a lot of Linux users/admins. These people need to learn > to walk first and rmemeber to close the front door before they start > armour plating the roof and putting a minefield in the front lawn =)Yup. -- Grant Taylor - gtaylor@picante.com - http://www.picante.com/~gtaylor/ Where do these people come from? Finger for PGP public key.
On Fri, Jul 10, 1998 at 07:38:43AM -0300, Grant Taylor wrote:>[...]> > This is not what I said. I merely point out that it is difficult or > perhaps impossible to make a "checklist" that will be complete enough > to result in a system that is actually secure. Particularly so over > time."Security" is relative. "Actually secure" makes it a binary choice. It aint so. [...]> > I have a car. I know how to drive it. I can change flat tires, add > > oil and gas. This covers about 99% of normal stuff. I take it to a > > car mechanic when it needs it. I am not going to stop on the side of > > the road, pull 200 pounds of tools out of the trunk and change all > > the gaskets in the engine. > > Absolutely. But network security is more complex than car > maintenance. It also differs in that "99% secure" isn't significantly > better than "40% secure".?? No attacker knows every exploit, and no sysadmin knows every exploit. The more holes you close the more likely you are to block up the ones that any particular attacker will know. "99% secure" is an almost completely meaningless statement, in any case.> Anyone interested in breaking in has only > to try out a bag of tricks until he hits that forgotten 1%.That assumes that the attackers bag of tricks includes that forgotten 1%. In fact, clue is not evenly distributed among the cracker community, either. A very few are brilliant and knowledgable, most are not. -- Kent Crispin, PAB Chair "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html
On Fri, Jul 10, 1998 at 07:38:43AM -0300, Grant Taylor wrote: [regarding <seifried@seifried.org>'s book]> And note that while I don't think that your book will actually > result in fully secure Linux systems run by neophytes, I do think > it's a net improvement in the state of the world. The more > material out there for people to learn from, the better...It therefore appears that everyone agrees that a Linux-specific security book would be a Good Thing -- the disagreement, then, appears to be about _why_ this would be so.>>>>> <seifried@seifried.org> writes: > > Theory is great but most people do not have the time, or technical > > background to read PUIS. To draw an analogy: > > > [ vehicle maintenance analogy ]> Absolutely. But network security is more complex than car > maintenance. It also differs in that "99% secure" isn't significantly > better than "40% secure". Anyone interested in breaking in has only > to try out a bag of tricks until he hits that forgotten 1%. OTOH, a > 99% well maintained car is very nearly indistinguishable from a 99.9% > well maintained car.I'm afraid I must disagree: I would find a system with 1% risk much more preferable than 60% risk, especially if the vulnerabilities are remote-root network exploits. You appear to be using an absolute model of "secure" vs. "unsecure" in which you claim 1% risk is the same as 60% risk. In that case, using your model, your Linux system is _insecure_ _right_ _now_, and there's nothing you can do about it. (PUIS 2nd ed., pg. 34 -- trust is introduced on page 26.) So while you are free to use whatever model you want, most of us are interested in practical applications of computer security, and that means risk assessment and mitigation ("less secure" vs. "more secure", not "unsecure" vs. "secure").> Hmm. An admin cannot secure something he does not understand.Admins can certainly mitigate system risks without understanding the details. For instance, if an admin gets email from a vendor telling her to "upgrade Sendmail/Perl/Whatever _now_", it doesn't require a lot of security savvy to figure out a) their system's risk of compromise has increased, and b) it will continue to increase in a time-dependent fashion until they upgrade.[1] Of course, it's _better_ if folks have a solid understanding of all nuances of computer security -- but for folks just starting out with Linux, who want to improve their systems' security posture, it doesn't seem appropriate to throw them a 900-page tome and tell them their system "can't be secure" unless they understand it. (Not only is it wrong, they'll _learn_ it's wrong when they get to page 34. ;) Again, the goal here is to mitigate risks. I can't see how a well-written Linux security tutorial wouldn't improve security within the Linux community. It might not cover all the bases (and it should be up front about that), but heck, neither does PUIS (which it freely admits). Further, I see that seifried's page already includes PUIS in the "Other Documents / Books" section -- that seems fair, since PUIS encourages its readers to examine OS-dependent documentation. Mr. seifried's paper seems to fit that category. Finally, let's refine what we're talking about:>> The only thing I can see coming out of a "checklist" security setup >> is a false sense of security.IMHO, this is incorrect. A "checklist", or tutorial, would help new users mitigate risks -- and the resulting improved security is real, not imagined.>> The moment poor Joe User does something unanticipated or tricky, >> he'll be both unaware of his problem and unable to handle it >> once/if detected. Conversely, a clueful user stands a chance at >> anticipating problems and being able to handle them.While that may be the case, I think it would be better to simply warn the tutorial's readers that this could be a danger, rather than abandon the tutorial. Mr. seifried, good luck with your book. Please make it a _good_ book. :) -Scott [1] As exploit information propagates through the grapevine, more and more people may potentially attack your system, which increases the risk of compromise. This seems to be the discrete case of a general security principal, where risk can be expressed as a function of time. For instance, smart Linux admins pipe the Linux-alert list to their pagers -- early warnings reduce risk, since not as many people have heard about the vulnerability. The general case: "Security through obscurity is not security." If someone has heard of a discussion of "Security through obscurity" as a function of time, I'd really appreciate a pointer. Thanks. /sd