Linux Security: Reflections on 2002, Eye on 2003

Mirko Zorz writes "Here are the reflections on Linux security in 2002 and predictions for 2003 by Bob Toxen, one of the 162 recognized developers of Berkeley UNIX and author of the acclaimed book "Real World Linux Security" already in its 2nd edition. Read more at Help Net Security."

Comments

Disappointing article

[Gogo Dodo]

That was a rather disappointing article. He only made one Linux-related prediction: that there will be a major Linux virus. Besides that, everything else was generic and not Linux specific.

Re:Disappointing article

[rde]

Think of it as a good sign. It's hard to write extensively on holes that don't exist. Or at least, ones that haven't been found yet. cronned apt jobbies and up2date, etc, mean that even the task up updating for newly-discovered vulnerabilities is easier, so it looks as if for the coming year, the biggest problem will be the users. Plus ca change...

Re:Disappointing article

[Slaven Reitmeier]

The predictions here were consistant with his '7 deadliest sins' which he frequently quotes. In fact, the article is in many ways just a more verbose version of them, with a few specific vulnerabilities thrown in for good measure.

Most of the predictions were "more of the same". I seriously doubt we'll be seeing "a major Cyberterrorism event" though -- I usually expect to hear this from sensationalists, not legitimate security experts. Think Steve Gibson. In fact, the theorized cause of these massive DDoS attacks is supposed to be windows systems, and the Raw Sockets are Evil thread is brought back to mind.

One big unforgivable mistake in the article: there was no bug in DNS -- there was a bug with BIND. Anyone using nameservers or libraries that were not part of BIND were unaffected. The fact that he assumes BIND is the only DNS server in the world is a big mistake, and one of the reasons DJBDNS doesn't get enough airtime.

Overall, I didn't see anything in the article that I didn't already see a hundred other places.

Personally, I'd like to hear what the authors of Hacking Linux Exposed have to say. Their book has a lot more grit and less soft-shoeing over the topics. Real World Linux Security has always been too full of stories and not enough answers for me. (Of course I bought the 2nd edition anyway.)

Near the end, end of honeypots?!

[pr0ntab]

He says that he predicts (and hopes) that the practice of using honeypots, etc. will decrease; that it only serves to illustrate to managers that security will be breached. Thus, we can assume that all sufficiently weak security will be breached eventually, ergo this practice is useless.

He forgets the other valuable feature of honeypots. You can deploy prototype installations and observe the kinds of attacks in the wild, to get a feel for the capabilities of the advisary. These techniques change over time, and that information is invaluable when determining where effort needs to be focused in a security plan for your product.

This short-sightedness casts doubt on some of the other parts of his essay, other than on the obvious points (to us at least, those involving Microsoft, Hollywood, the man keepin us down, blah blah blah)

Re:Damn

[JoeBuck]

Yeah, and I'll bet he gives his credit card to waiters in restaurants all the time. The only time I've ever had someone try to use a credit card number stolen from me, it was a busboy at a local Cambodian restaurant (they caught the guy too).

Security predictions

[ACK!!]

Yeah, people act like only MS can get infected with a virus but there will be a major linux virus soon. It is going to happen. As linux gets more exposure more schmucks will write malicious code designed for busting up linux boxes. It is not like the Unix world is some foolproof world of rock hard servers.

After all, why did linux inherit the Unix concern for security?

Enough old-school unix guys have been bitten by the bad security in telnet and NIS and a half dozen old world Unix services with big nasty security issues.

Sure Bastille linux or RedHat secure server makes decent choice and OpenBSD is locked pretty tight right out of the box. That does not mean that it is impossible to break into those boxes. Just that it is more difficult. All you need is a one-day lag between a security issue posting on Cert and the patch to whatever software you are using coming up for your distro or OS. It can happen to any of us. It will happen to many of us.

The over-confident are always the funniest to watch when their shit hits the fan.

The honeypot thing is interesting. I have always wondered if you really get enough useful information from the attacks to warrant the time put into the systems. Somehow it just smacks of a geeky wanking waste of time. On the other hand, maybe the information from such implementations really make this worth it.

Any comments on this?

Re:Security predictions

[zatz]

I think the executable versions, library versions, and specific configurations of services vary a lot more between Linux boxen than Windows hosts. There is much less of a monoculture problem, so it is more difficult for any single worm to infect a large fraction of hosts.

Still, as Linux slowly gains desktop market space and the level of security awareness of the average user declines, it is conceivable that it will become more hospitable to Nimda/Klez-scale worm epidemics. Also Linux tends to run more services; a Windows 98 box is very difficult to compromise remotely because it has almost no interfaces to subvert. We probably won't be at the same level of susceptibility as Micros~1 platforms for a while, though.

RWLS != most important

[Anonymous Coward]

If you consider Toxen's book "one of the industry's most important books on computer security" then you must be defining the industry as "people who want to read a lot of great stories about the good old hacker days, and don't care if we get any useful answers for security on your linux machine."

No, this is not a troll, it's my book review. Toxen should write a book about his days working with the BSD folks, he'd sell a million. But as a Linux security book, I'd suggest the man pages first.

Linux securty? Be more specific. Kernel | Userland

[Anonymous Coward]

All security is an issue of the userland software, not necessarily the Linux kernel itself. The userland software in question is: all of it.

Software that uses suid bit set will still be susceptible to leaving control to the "root" user after it crashes. Telnet and SSH still allows people to do bad things, as well as good things, to the hosted account's property.

Alas, the Linux kernel is a perfect angel...but hark, what do I see? A "Tux" http server in kernel space? That is quite dangerous. No matter what the performance benefits, leave those kind of user-services outside of the kernel because each and every bit of code in kernel land makes the Linux kernel that much more closer to an "unknown" exploit. /other than that, the userland tools taste like chicken and the kernel still smells like hering.

"Worldwide recession"

[Sara Chan]

The article talks about "the worldwide recession". A recession is typically defined as two consecutive quarters (i.e. six months) of negative GDP growth. The Economist gives the most-recent GDP changes data for each of 19 different Western countries (sorry, not free). Only two are negative (Denmark and Norway). The most-recent quarterly GDP change for the the Euro area is +1.3%; for the USA it is +4.0%.

There is a rationalization going on in business IT. This is not a recession at all.

Huh?

[Mandi Walls]

Ah, yes. Another whiny little post about RPM-based distros.

As another responder so aptly pointed out, the package management system has nothing to do with security, unless you are using file verification as part of your security plan (which isn't a bad idea.. do "rpm -Va" for system-wide verification of all files known about in the rpm database).

However, if you have to support real-world applications, and not just your webserver at the other end of your cable modem, there is another aspect to system security and stability, and that is THIRD PARTY VENDOR SUPPORT.

Now, I realize that the number of guys on /. who actually do stuff for a living that doesn't include final exams is minimal. However, if my boss/engineering staff/customer wants a product for a specific purpose, say, backups, or CRM, or CMS, I don't have the power to say "well, sorry, but we only run StinkyFeet Linux, not Blue Bonnet like that vendor requires". If they don't can me, they'll just go with a Windows-based app to get around that headache.

So then, what good does it do to have several distros around? They all run the SAME PACKAGES, imagine that! And when there is a hole in OpenSausageStuffer on an RPM-based distro, there is going to be a hole in OpenSausageStuffer on a non-RPM-based distro. The Horror!

So instead of having one distro network-wide, which has the same version/feature set across all systems, and the same cronjobs for updates, etc, i now have several, because some fool decided that he didn't have the time to make the appropriate decisions and shut things off. hmmm...

And that doesn't even get into the headache of trying to deploy my own packages, or dealing with the preferences of my users, or with the terms of a contract.

In short, being a stick in the mud about distros isn't going to gain you anything. And not learning how to do your own security in favor of a crutch like Bastille isn't going to gain you anything either. Jay has a good idea, and it's great for noobs, but if I'm paying you (or if you're paying me) to secure a system you better fucking know exactly what is going on. And when security requirements change, you better be able to handle it. Relying on someone else's idea of secure is a place to start, not the final answer to your own security. Security is a process, not a product, no matter what your little imagination tells you.

When it comes to system security, the best distro for the job is the distro you know the best, not the /. poster's favorite distro. A newbie to HandCreamBSD isn't going to be any better off than a newbie to Blue Bonnet Linux.

--mandi

Re:Near the end, end of honeypots!

[Real World Linux Sec]

A honeypot is not the best way to test the security of a prototype installation either. The time spent with the honeypot would be better spent selecting a secure platform to develop on, designing rules for writing secure code, and doing code audits and security audits, etc.

If the honeypot is not breached is the system secure? Of course not. You have learned nothing. If you instead did that code audit and security audit then you would have more confidence that it was secure than when you started.

I stand by my claim that for most people, the time spent on a honeypot does not have technical value.