Reflecting on Linux Security in 2003

LogError writes "Here's a look at some interesting happenings with Linux security in 2003 with comments by Bob Toxen (one of the 162 recognized developers of Berkeley UNIX and author of "Real World Linux Security") and Marcel Gagne (President of Salmar Consulting, Inc. and author of "Linux System Administration - A User's Guide" and "Moving to Linux")."

Comments

Nice idea (?)

[Elie De Brauwer]

Quote from the article: SecurityFocus columnist Hall Flynn notes that he doesn't understand why Linux vendors that put so much time and money into creating security patches distribute them for free. --> Just imagine the amount of e-mail worms there could be out there if people would have to pay for outlook updates.

Re:Nice idea (?)

[Mostly a lurker]

I think that security updates for ANY OS or application, irregardless of the status of its source code, should be free and available for everyone.

I am not disagreeing, but there is an implied assumption in your post: that fixes are always available. A serious security issue will rapidly be fixed in any widely used open source product. With closed source products, provision of a fix is at the whim of the vendor, and serious security exposures can sometimes go months without a fix.

Re:Nice idea (?)

[Cody Hatch]

Mmm, your close. More correct would be:

Forcing people to pay for security updates would be stupid IF it guaranteed the insecurity of a greater number of Internet-connected machines.

You are, of course, assuming that a smaller percentage of people will install the available patches if they have to pay - which is obviously true. You are also assuming that nobody will be lured to write a patch for an unsolved vulnerability by the thought of large piles of cash, which is obviously incorrect.

To put it another way, by limiting the price to zero, you will cause a shift in both the quantity demanded and the quantity supplied. When there is a shift in both, you can make no conclusions about the net effect on the equilibrium point. :-)

In *general*, it would be quite silly to charge for a patch to Apache - but its easy to imagine a specific case (maybe a remote root exploit) where volunteers might be able to deliver a patch in 36 hours, but someone might be willing to pay for a patch delivered in 12 hours[1], even knowing that another 24 hours would give them a comparable patch for free.

In that situation, how could you possibly argue that banning payment (meaning there won't be any patch for the full 36 hours) possibly do any good? Or for an even better example, what about for a program so old and/or obscure it simply won't BE patched if someone doesn't pay?

[1]: Feel free to substitute your own times if it makes the example seem more realistic to you. Hours, days, weeks, minutes.

Re:Head, meet Sand

[divide overflow]

> From the looks of things, they still have a while to go. IMO, Linux people talking about security is like that saying about people who live in glass houses.

Note that many if not most of the vulnerable programs shown in your link to securitytracker.com are not related to the Linux kernel nor part of most Linux distributions. This makes for a potential "apples to oranges" comparison with Windows vulnerabilities.

Re:Head, meet Sand

[t0ny]

Apparently you missed that story last month regarding the hack which exploited a Kernel bug. This effected ALL distros, since it was a kernel exploit.

Also, the page for Windows doesnt just list OS components either. So, as far as security tracker goes, it IS apples to apples. One can also argue that IIS is not really a Windows component, since it is an optional service. But thats the way they organize their site. If you dont like it, talk to Security Tracker; Im sure they would be happy to hear from you!

Best security fix in Linux: 'tar'

[jkrise]

A simple backup-restore utility that allows users to backup all their filesystems, and restore them in the event of a crash. A separate unnmounted filesystem to store the 'image' - no worm can get past this simple strategy. A major security breach? Simple:

1. Remove network cable (OR) Internet connection.
2. Boot from tomsrtbt
3. Mount backup partition(s)
4. Run simple restore script.
5. Reboot and enjoy!

Can any other OS do this, with off-the-OS tools?

-

Re:Head, meet Sand

[C10H14N2]

Don't throw stones inside your modded linux box?

Right, Check.

As for security, that would explain why my Linux boxes have for years been under constant attack from compromised Windows machines without incident.

Re:Security

[dexterpexter]

I absolutely agree with every point in your bulleted list. But the short answer is yes, I do believe that bugs make it into code because of emphasis on cranking out software quickly. It would seem illogical to do so, true, but the sad truth is that it happens and I have watched in horror as it has happned at the place at which I work. When the CEO comes in screaming "ship it! ship it!" and you are given very little alternative, that is exactly what happens. And yes, it does cost more money to repair the bugs later than sooner, but management knows no logic, and developers many times get no say in when their project ships.

Jack Ganssle gave a very nice keynote speech at the recent Boston Embedded Systems Conference that touched on those very same problems. We all know better, but it still happens. And no, not just at M$. However, when you can crank out a new OS every couple of years and the sheep still buy it despite knowing that the OS is unstable, then why not?

Some of the security holes that we have seen come from M$ products (and other products as well!) show the lack of real testing... problems that never should have been seen by the end user.

Re:SSH and SSL

[jc42]

I think it's ironic that the two things I had to patch most often this year were OpenSSH and OpenSSL.

Well, I'd think that this is a Good Sign. The term "secure" doesn't really mean that no holes exist. That's hardly likely. What it really means is that no holes are known. Or, a hole was just discovered, and we're working furiously to fix it.

The fact that these patches came out really mean that the OpenSS[HL] crowd is 1) actively looking for problems, and 2) fixing them rapidly. In particular, they don't hide the problems behind a shield of secrecy, and they don't collect patches into sets to be released when the PR people decide it's appropriate.

If their patches taper off, it will be time to take a skeptical look, to make sure that people are still actively attacking the OpenSS* code and trying to poke holes. If this process stops, we should worry. If people are still studying and attacking the code, but failing to find holes, we'll know we're in good shape.

But we aren't quite there yet. So the patches are a Good Thing.