Slashdot Mirror
Security Holes Draw Linux Developers' Ire
jd writes "In what looks to be a split that could potentially undermine efforts to assure people that Linux is secure and stable, the developers of the GRSecurity kit and RSBAC are getting increasingly angry over security holes in Linux and the design of the Linux Security Modules. LWN has published a short article by Brad Spengler, the guy behind GRSecurity and it has stoked up a fierce storm, with claims of critical patches being ignored, good security practices being ignored for political reasons, etc. Regardless of the merits of the case by either side, this needs to be aired and examined before it becomes more of a problem. Especially in light of the recent kernel vulnerability debated on Slashdot."
Given that I'm getting lousy uptimes on my Linux servers because of the mandatory kernel upgrades, I certainly welcome a (constructive) critical look at Linux kernel security.
see a Text Widget
It's interesting to note that this comes out so recently after Linus was named one of ITs best managers. Lord knows he'd have to be to keep so many disgruntled people quelled. In the followup, somebody was citing as an excuse that Linus is one person and that there's only 24 hours in the day, so maybe some patches get missed. I was wondering, with all of the people he delegates to, isn't there somebody who handles all the security issues? Scroll down the LWN article, and somebody mentions that he needs a Kernel Security Officer, with no follow-up. Does Linus not have one of these guys yet?
The trade off between security versus usability/accessability begins?
Will Linux strike the perfect balance? Will Linux be taken over by a lunatic like Theo and go the OpenBSD route? Will Linux lose it's viginity to Windows and become a security nightmare? Stay tuned! All this and more on the next episode of OS wars!
The bug mentioned in the LWN article was apparently not treated as serious by Andrew Morton and other developers on the grounds that there are far easier ways to DoS a system without using kernel exploits like that one. I don't know whether that's good or bad, but from debating things with various PaX guys myself I know they have a rather extreme approach to security (not something I'd ever give my grandma ...)
There are tons of services that you can't just pop a couple machines together and tada, they are loadbalanced. Just because its easy for simple things like http and smtp, doesn't mean its easy for everything.
OpenBSD has implemented security similar to grsecurity. Note that this is part of OpenBSD operating system, so the user does not need to do anything to use it. Contrast this to grsecurity that is a set of patches against Linux kernel.
As far as I know, only Gentoo and Mandrake supports grsecurity.
Lesbian Nazi Hookers Abducted by UFOs and Forced Into Weight Loss Programs - -all next week on Town Talk.
Maybe it's time everybody get off of their OS Religious High Horse and finally admited that an OS is only as stable and secure as the user who is administering it.
My Windows XP machine is solid and secure. My FreeBSD machine is solid and secure. My Windows ME machine -- well -- it runs, and it's quarenteened so I suppose in some ways it's secure.
Right now I'm installing Gentoo on a box so I'm going to see where this goes, but I am going into it with full realization that no OS is perfect, nor is it perfectly secure. This means that I'm going to take security as seriously with this machine as I do the rest of them.
Having the source to an OS doesn't make it more secure if you don't read (or understand) every line of it.
Why people think OSS is automatically more secure is something I never have really understood. There is some added comfort in knowing that most holes will be discovered and fixed promptly, but even that is an assumption one shouldn't bank on.
"Everything you know is wrong. (And stupid.)"
Moderation Totals: Wrong=2, Stupid=3, Total=5.
Grsecurity guys (Brad and the pax guy mostly) are dead serious. They have been researching their areas of memory management, protection and secure code for years. They really do know it pretty much all. For instance the "AMD NX protection!!!!" that the Redhat raved about was copied from Pax. (Without even crediting properly.)
They are just the sort of real gurus that can spot new vulnerabilities from code and exploit them in a matter of minutes. When Grsecurity was having serious funding problems last summer Brad was forced to sell new vulnerabilities from Linux kernel code to unmentioned blackhat companies. (Those do exist, believe me. They are doing commercial intelligence, stealing trade secrets with the knownledge..)
Those guys are technically brilliant, years ahead of what Linux stock kernel has in security features. They are just a bit arrogant and bad with people. Also at the same moment the upstream kernel developers don't like being told that their stuff is complete crap on some area. They downplay it, ignore and use the "whoareyou,Iamthekerneldeveloper,youknownothing" tactic.
Grsecurity guys could absolutely smash LSM by showing the vulnerabilities they are talking about as pocs. They are just a bit too disgusted and pissed off. There are several other areas like the exec_shield (that *is* atm getting to upstream kernel) that have big faults as well...
They could prove their other points as well.. But it would be moot since they ARE correct in any case.
If I read you correctly you're saying that Linux's new-found popularity will cause lots of previously unknown security flaws to become evident. Do you believe either (a) Linux will ultimately have a similar number of security flaws as the Windows kernel, or (b) Linux will ultimately have a similar number of security flaws as Apache (an open-source, industry-leading application)?
What I'm getting at is: security through obscurity is largely regarded as flawed (outside military intelligence circles), and the open-source/free-software development model has - time and again - resulted in bugs being shallow (IIS is closed-source and buggy. Apache is open-source and - relatively - secure).
Everytime - everytime! - there's a security issue with Linux a troll pops up and says "ha! ha!" in their best Nelson Muntz voice: as if Linux was somehow perfect, but has now spectacularly fallen from grace. I don't know whether you're trolling as you don't really say much, and I found it difficult to understand much of what you did say, so my apologies if I'm way off base here, but...are you suggesting that Windows is "more secure than Linux", or what?
This is where the serious fun begins.
I wouldn't be surprised if Linux is less secure than the NT kernel. NT has much finer grained access control than Linux (although not if you include SELinux), and I haven't heard anything about kernel exploits in Windows for a while (although this may be because I haven't been paying attention). The problem with Windows is all of the cruft on top of the kernel that doesn't need to be run with administrator privileges, but is, and is full of security holes.
I am TheRaven on Soylent News
holes in the kernel have been allowed to go on as long as they have?
Allowed to go as long as they have...by whom? By the volunteers devoting their time to kernel hacking? I'll give you the benefit of the doubt and assume you're an active kernel hacker...
You compared Linux to Windows in your original post: how many security holes in Windows still remain, years after they were first reported? (For that matter, how many holes are we still unaware of, because the source-code is closed?) Why have these security holes been allowed to go on as long as they have? (Answer: because resources are finite; and Microsoft has other things to focus on. Likewise for Linux. If you feel that too few resources are devoted to security in the kernel: volunteer. Or criticize and offer no helpful solutions. I choose option A).
This is where the serious fun begins.
With 2.6 there seems to be a bad trend towards far too much politics in the kernel. The cdrecord problems and reiser4 business (did that ever get sorted out?) together with the IMO stupid policy of putting new features in the stable branch (making deciding whether a feature can be added much harder, since it needs to be that much more stable and necessary before it can be added, but often you can't prove it's necessary without having some kernel branch running with it in) all smack of too much politics. Why can't people just concentrate on making the best kernel possible?
I am trolling
Long-time shell-provider SDF used Linux
Now, it's a 64-bit version of NetBSD.
OpenBSD claims:
"Only one remote hole in the default install,
in more than 8 years!"
Why not start with a core built for security,
- ie, rather than one built for popularity?
My two cents...
So ... rather than ask on the mailing list who is the best person for security submissions relating to whatever bug he found, he emails the top dude (during Christmas holidays no less) and then whines when no answer is forthcoming within his preferred timeline. Gimme a break!
As a total noob, I went to kernel,org and found this on the first page:n g-bugs.html if you want to report a Linux kernel bug.
Please see http://www.kernel.org/pub/linux/docs/lkml/reporti
http://www.tux.org/lkml/#ss5 explains why XX doesn't answer emails - too fricking busy is the usual reason.
If I were concerned about publishing the bug, I would have asked ON THE LKML LIST for who would be the best person to submit security-related bug and patch to for the XX module.
I emailed Bill Gates to say that with a tunnelling electron microscope someone could adjust the logic in the CPU and DOS WindowsXP, and he hasn't answered me. Pout!
_O_
.|< The named which can be named is not the true named
So many people are missing the point. It's Linux, it's open source, you're not living under a Sun or MS dictatorship. If you don't like what Linus is doing, either maintain a separate set of patches or fork the kernel. I mean Jesus, SuSE patches the vanilla kernel, RedHat patches the vanilla kernel, Mandrake patches the vanilla kernel, and want to know what ... I maintain a set of patches that I apply to my SuSE patched kernel sources *SHOCK*. Just because Linus refuses a patch doesn't mean the end of the f-ing world is neigh.
I hacked my kernel to "solve" the uselib() problem. "Solve" is the wrong word, because all I did was perform an appendectomy; I replaced the body of sys_uselib() in fs/exec.c with the single line:
return -ENOSYS;
so any code that calls uselib() (which is an utterly obsolete syscall that hasn't been legitimately used for years) will simply fail with a "function not implemented" error.
It's not a real fix. The real problem is a locking issue in do_brk(); the uselib() alert was simply one way to exploit it. But it'll do for now.
-Stephen
If I'm running 2.6.8, and a new bug comes out, I'm forced to either A) upgrade to the most recent 'stable' kernel, introducing new features about which I know nothing, and which themselves may be security problems, or B) can hope that someone will backport the security fixes to the kernel version I'm running. I don't know enough about kernel development to patch it myself, but I can no longer just drop in the most recent stable kernel and expect it to work unchanged.
A sysadmin's most precious commodities are time and attention. With this new development model, suddenly I am forced to either pay a great deal of attention (and a great deal of time) to each and every version of the Linux kernel, or I need to pay a vendor to do it for me.
The kernel developers are, in my opinion, shirking their single most fundamental duty... to ship a stable, secure product. Suddenly, because it's easier for them, they have abrogated the fundamental contract, that they will write great software. (buggy, insecure software is not great, no matter how many features it has.) They just wave their hands vaguely in the air and say tha the distributions will take care of those problems.
Guys, it's not gonna happen. The way you get stable software is by not adding features. In your case, by branching off to 2.7, and letting us beat the unchanging (except for bugfixes) 2.6 tree to death. If you keep adding features, you keep adding bugs. That's how it works.
You had this NAILED for years and years... there is a huge community that has built up around the fundamental social contract that even numbered kernels are as stable and secure as you know how to make them, and the odd-numbered branches are the home for new code and new features. Changing that contract simply becuase it makes your lives mildly easier is a hugely destructive idea. You may save yourselves a bit of work, but you create an enormous amount of it for everyone else.
Ted T'So said:
In other words, he thinks it's perfectly fine if only 1 out of 3 'stable' kernels are actually stable.This is not acceptable.
You can bet that Bill has a big grin on his face about this one. If I want new features with my security fixes, I might as well choose Microsoft and their service packs.
Heck, they even have a QA team!
And I'll aggree with you about that mindset and hipocrisy too. That's what ticks me off too. The doublespeak and double standards, where the same thing is a hanging offense if it's in Windows, but normal and doesn't even really need a fix if it's in Linux.
But just to add a couple of minor details:
A) I'd argue that Microsoft didn't start secure and slowly get down the drain. They started by ignoring security outright.
E.g., if I remember right, for example, the file server security in NT 3.5 and the pre-SP1 NT 4.0 was entirely in the client. Yes, the client was supposed to check for itself if it's allowed to access a file, and if not, back down. However, if the client was not that nice, it could go ahead and request the file anyway... and get it.
E.g., MS Bob, in the name of userfriendliness, asked you to change the password if you miss-typed it 3 times. No, not if you successfully logged in after mis-typing it 3 times. That's it. Three failed attempts in a row, and you can set a new password.
Etc. I could go on for ever, but these are ludicrious enough to illustrate the point: MS didn't start making a compromise here and there. It outright ignored security until it bit them in the ass.
B) But to be fair, so did everyone else, and some still do.
E.g., it's not a case of Linux eventually getting as insecure as MS Windows. Linux already _was_ less secure than Windows, oh, say around the time Windows 2000 was released.
Sorry, I'll probably annoy the pinguinistas, but taking a Linux system as root online back then, meant you had a script kiddie logged in withing hours at most. _And_ most distros made the same MS mistake of installing and starting every possible service by default, and no firewall either. I know my SuSE systems got Apache, MySQL and God knows what else if I didn't uncheck those at install time.
It took some code reviews paid for by RedHat and the like, before Linux was anywhere _near_ secure.
C) Basically, sad to say, much as nerds balk at "clueless lusers" running without a firewall or MS for having exploitable bugs, most are just as clueless themselves when it comes to writing secure code.
And I don't mean just bugs or lack of communication ("oh, I thought YOUR function checked the buffer length already.") I mean outright lacking even the most elementary clue about secure design, and not giving even the bare minimum thought to what could happen.
Just as end lusers think they're safe without a firewall because they don't directly see the script kiddie breaking in, coders tend to ignore the unseen threats just as well. Mentalities like "oh, surely noone will edit the id in the URL and make themselves superuser" are the norm, not the exception. Or at most they'll repeat mantras they've heard before, without even understanding what those mantras mean.
It's not even a MS vs Linux thing. Windows, Linux, Solaris, whatever. Unless you have some security minded people trying hard to find a bug or way in, you end up with a catastrophe. The average coder's work is a heap of security holes waiting to be exploited.
A polar bear is a cartesian bear after a coordinate transform.
I experience the same feeling with S-ATA. There is an obvious issue with the S-ATA driver, which leads to data corruption with many drives and controlers (especially the Silicon Image 3112). But rather to stick on this problem until it's resolved, developers seems to continue in the "it's the hardware's fault" kind of statements. Nevertheless, one of my colleague, a NetBSD expert, tells me that this data corruption with S-ATA does not appear on NetBSD. And when I look in NetBSD mailing lists, I found nothing about data corruption on NetBSD. So what's next for Linux?
RIP Slashdot. I used to love you. dead account - but slashdot wont let me delete it.
Some of these bugs, according to the article, have been around for ages, so the new dev model isn't to blame. But Linus and Andrew didn't even respond to these critical vulnerabilities....
Just go ahead and create a 2.7 branch, and then assign a maintainer to the 2.6 branch and let it stabilize. I don't see any reason for not doing this.
Buses stop at a bus station
Trains stop at a train station
On my desk there's a workstation....
You're absolutely correct in what you say.
:)
2.6 is currently a developer's dream and an administrator's nightmare.
It is a smoking pile of bleeding edge patchwork. It can do everything in double time and brew coffee concurrently, but it cannot serve a file reliably (for example - as outrageous as it sounds that last part is actually the truth).
The absolute major top-1 problem is the huge flux of patches; 4000 changesets between 2.6.9 and 2.6.10... One kernel fixes maybe 100 bugs and introduces the same number along with a heap of new features while it deprecates a few old interfaces.
If 2.6.5 is the latest stable 2.6 kernel for one particular use (which I know for a fact that it is for some uses), you're stuck with a local root vulnerability because most likely 2.6.11 which may have a fix for this one bug will crash with that workload (as 2.6.6-2.6.10 did).
And the examples I'm pulling out here (file serving and many unstable kernels in a row) are not unreported problems. They are not new problems. They have been worked on, partially fixed, etc. etc. but with the development model as it is, you just cannot expect fixes to have a very long life-time.
It is very very sad. But I think it will change as someone realizes how bad the situation is. Probably half a year or so from now, when people start getting really annoyed that you *still* cannot route, web-serve or file-serve in any significant volume with Linux 2.6.
Until then, it's Linux 2.4 and Solaris - both slow compared to 2.6 maybe, but at least they stay up over night
These kinds of security problems leave the door open for someone else to determine the future of Linux.
You've just handed Microsoft a huge Public Relations goodie that they can beat to death as definitive proof that Linux fails to promptly fix security bugs. And now it can be extended to a universal problem with all Open Source Software. And now everything is back to being Microsoft or Death.
Sure I exaggerate, but don't you think others will try to do the same?
I don't know if the guy from GRsecurity can be classified as an asshole or not. I have found a lot of people who do post security patches tend to be very arrogant buttholes, but I've never met the guy. So there's some room here to determine just who's the bitch now.
But if these are real security holes and have been around this long, we've lost a tremendous edge on what advantage Linux has been able to claim in the past. The door is open.
My guess is that the best candidate is going to be OpenBSD or one of the other BSD's. It wouldn't surprise me. As something goes mainstream, it's political fat starts to overwhelm it's technical agility. To prevent this you have to fight very hard. Feature Creep is one name for this phenomenon. It could be argued that Linux has become focused on providing new and interesting features over old and boring performance expectations. This is to be expected as more people start pressing for wish list features and begin to ignore the original problems of security and stability. If you've ever wanted to see this in action - watch Debian. People are bitching now that Debian Unstable should be the defacto distribution version today and just wave their hands in dismissal when someone complains about packages breaking in Unstable. Apparently they too have accepted inherent stability problems in lieu of stability.
This is dangerous for all organizations who do this. As the foundation is ignored, you will start to permit some really illusive bugs into the system.
Similar extensions can be found when comparing Debian's Stable to Mandrake et al. Debian tends to be much slower on new developments, but they have a very good track record for basic performance. Similarly OpenBSD has it's software/hardware limitations, but it's definitely secure.
And any arguements regarding the security of a system as installed from the distro-provider is pretty much BS. They have each decided to install towards a target audience. To expect to be able to execute an installation on an unprotected machine and have no security holes appear at any point in the process is more trouble than it's worth. The price of doing an installation behind a firewall is far lower and a waste of development resources.