Security Holes Draw Linux Developers' Ire 477
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."
Interesting point of view (Score:2, Interesting)
Re:Time for (even) better security? (Score:4, Interesting)
distro with grsecurity (Score:3, Interesting)
Re:Here it comes (Score:5, Interesting)
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?
Re:Microsoft? (Score:5, Interesting)
Ok, so where are the patches? (Score:3, Interesting)
The fact that it doesn't even show up in bugzilla makes me think it's still under embargo for some reason. Shouldn't the leak be sufficient reason to change their timeline? For those of us running production servers, this waiting game is more than a little inconvenient.
On a side note, from what I've seen, the exploit has only been demonstrated on uniprocessor 2.4 kernels. Anyone get it to work on an SMP kernel, or a 2.6 kernel?
Re:Time for (even) better security? (Score:2, Interesting)
What change would you ever be making that affects startup? Especially if it's a non-shell server, the chances of you needing to change something that affects bootup is miniscule. My Solaris servers have been running for 2 years straight. I don't bother to upgrade the kernel because: a) It's running stable, b) I don't need any of the bug fixes or new features, see "a", c) it's just a DNS server so no users log into it to exploit any local holes. I keep BIND up to date and that's it.
Wrong Recipient? (Score:4, Interesting)
Re:Time for (even) better security? (Score:5, Interesting)
Either you aim for excellence or you don't. Getting this right is a pretty hard thing, but if you start making excuses and getting into workarounds you end up some years down where MS is today: A nightmare of workarounds and makeshift solutions barely held together with pieces of string and duct tape. They also started out with making a compromise here and a compromise there and saying "Oh, this won't matter much, let's do this later". You see where it got them.
Trying to get the code right is an important part of this. If you don't get it right the first time, fine, then review the code and patch it, but do it right. Not just one bug today, and another one of the same kind tomorrow, and the third the next week.
If someone knowledgeable is able to find a series of similar bugs in a widely used and widely reviewed piece of code like the Linux kernel in a couple if minutes and if bugs are mostly fixed in a piecemeal fashion getting us to the kernel security bug of the day (we are now almost at the kernel bug of the week already) the Linux community should say "Hey, could we do something better ?" instead of saying "Doesn't matter, use a workaround and there are worse vulnerabilities anyway, so what ?"
Re:Microsoft? (Score:2, Interesting)
Fine grain control doesn't realy have much to do with the kernel.
What SELinux is is Mandatory Access Controls. Or MAC
What the standard Unix (and Windows) model is discretionary access control.
What this means is that your access is based on your UID and GUID. If you have permission or not to access a file.
Mandatory Access control allows you to control access based on BEHAVIOR and other criteria.
So say your a idiot and run Apache webserver as root. If your Apache server gets attacked and successfully comprimised then if you only have DAC permissions then your system is laid wide open for attackers.
If you do the same thing with a MAC setup then even if they comprimise Apache and get root then they still can't do jack shit because you have the Apache proccess setup to only allow certain behaviors nessicary to operate itself all else access is denied and it doesn't matter if you have a UID of 0.
You can set it up so that if you log in as root thru SSH you have different access controls then when you log in thru a local virtual console or use SU to obtain it.
Windows doesn't have anything that comes close to this sort of thing.
As for the ACL's that Windows uses, Linux has those in the form of Posix-compatable ACLs.
Most distros support this, but it's disabled by default.
Why?
because it's not needed. Finer grain = more likely to fuck up.
90% of the time when a person thinks they need it, they simply aren't being creative enough to figure out a better solution.
If your smart enough to get to the point were you realy need it then you know out to turn it on, and it's very simple. Basicly it amounts to a -o remount and a couple other options.
Fedora Core3 uses SELinux by default. The Gsecurity complaints about the LSM is misguided and obsolete, it already has been used to allow things like low-latency sound server JACK setup for audio workstations and other purposes that wouldn't be possible.
This article is CRAP. It's a troll pure and simple and a way to stir up bullshit.
Linux actually has a pretty decent track record and the lack of a 2.7 development kernel wouldn't of stopped this latest flaw because it was something that existed since before 2.4 (were there always has been a development kernel).
Linux has it's security issues, always has. OpenBSD is what you use when you want something deadly secure, but it's 10x better then anything coming out of the windows world.
That's why people say that "Linux is more secure", not "Linux is the most secure OS ever made and will never have any security issues whatsoever"
This GSecurity has provided a usefull service in reporting bugs, but this isn't the first time that he has tried to drum up controversy. First time was threatening to take gsecurity down because lack of support, then the SELinux crap, and now that Linus doesn't respond to crappily labeled e-mails.
Linus gets LOTS of e-mail. It's just something that got lost in the shuffle. There are people that are incharge of this sort of thing and gsecurity should of contacted them in order to get the issue resolved quickly.
It would be like emailing billg@microsoft.com to report a bug in Windows.
Before this there was a spat over Linus disabling the ability for people to access the scsi stuff thru setuid.
This disabled the ability to burn cds as a user using certain programs.
This was done for security reasons and people Bitched and moaned how Linus +friends cared to much about security and didn't give a shit that linux would loose users because now they have to use sudo to burn cds.
Basicly.
It's blowing a problem out of porportions.
Re:Time for (even) better security? (Score:3, Interesting)
If you're bashing me because you thought that I claim that uptime should take any priority over security: well, I do not hold that position.
We routinely patch other software running on our systems, but those do not involve reboots and are easier to fix in case of problems. I do not see a problem with wishing for a lower frequency of mandatory upgrades of the kernel. What makes an upgrade mandatory is the fact that it is vulnerable, not that a manager demands it.
As for the problem with your admins: I get the impression that most of the burden of an intrusion does not fall on their shoulders. If it did, they would be a lot more paranoid about security and would take more initiatives in fixing (potential) problems.
Re:Maybe it's time... (Score:3, Interesting)
what does that mean? only a few serious exploits compared to dozens? That may be the case, but a naughty person only needs one to root you
Re:wow... (Score:2, Interesting)
of course, trying to be a smartass instead of reading the article and the linked URLs where all this has already been explained is sooo much more trendy here.
Re:Bugtraq rulez. (Score:3, Interesting)
Re:Maybe it's time... (Score:1, Interesting)
I'll go one step further to say that a proprietary OS is inherently more secure than open source.
I know that probably sounds like a bizarre and perhaps even insane statement to make considering the sheer number of MS secuirty hole headlines here on Slashdot, however, it's based on things I don't feel very many people take into consideration.
The people working on Mac OS and Windows are the absolute top of their field. Apple and MS do not hire any random Joe with a Space Invaders clone in their portfolio, they only hire amazingly talented and intelligent people that know a whole lot more than you.
Many posters on Slashdot have the Monday Morning Quarterback syndrome. They are quick to judge and criticize, but if they ever found themselves in the big game they'd quickly realize just how unqualified they are to definativly state the right way, or even more so, the wrong way to do something. They'd realize that there is a whole lot more to the equation than they can see.
Most people working on open source do so freely in their spare time. Their ability to contribute is limited much more by their freetime than their skill level. Rightly so, they have no accountability for the project. If it doesn't work, you can't complain, it was free after all. If it eats your entire system, you can't complain, it was free.
So if you consider all the factors, proprietary is indeed "inherently" more secure than open source. A highly skilled professional chosen out of thousands of applicants, getting paid to work on a project full time, and knowing that major mistakes can drastically impact his way of life is more likely to produce a secure product than someone with unspecified training, working in their free time, with no accountability to the project.
Keep in mind that I'm not saying open source is less secure. I'm saying, in general, I am personally more apt to trust the security of a proprietary OS because of the ambiguous qualifications accountability of open source developers. Just as I am more apt to trust a board certified surgeon working through a hospital than a person of unknown qualification working out of a leased office. Two months down the line if I have problems I know the hospital is still going to be there whether the surgeon is or not, and because of that there is a pretty high level of security. Whereas 2 months down the line that leased office might be in use by a nail salon and the person with the unknown qualifications is nowhere to be found.
Leaving the Door open for someone else (Score:5, Interesting)
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.
Re:Maybe it's time... (Score:3, Interesting)
Oh I do love the sweet innocence of youth. It's so refreshing to us old cynics.
Where on earth did you get the idea that boneheaded mistakes aren't designed into Unix-like systems? Do you really believe that the Berkely r-commands (rcp, rsh, ...) weren't known to be insecure on anything but a friendly LAN? Do you really believe that people didn't know that clear text passwords for ftp and telnet couldn't be snooped on the wire, long before such snoopers became widespread?
Here is a real-life bone-headed mistake engineered in to a Unix variant, and one I helped uncover. Back in the mists of early history, DEC produced something called Ultrix. Even in those days, password crackers were widespread (I had a hand in Crack's development but that wasn't the only one, just one of the most effective) and DEC needed to be seen to be doing something. To summarize somewhat: they replaced the crypt() function with crypt16() which was supposedly much more secure. For a start, they allowed 16-character passwords compared to crypt()'s 8-char limit --- hence the name, I guess. Without seeing either source or disassembling the library's binary I reversed engineered it. The initial breakthrough was discovering that both routines took exactly the same time to hash a password, within measurement errors. It was clear that both were using 25 rounds of modified DES. Experimentation showed that crypt16() ran the first 8 chars of the password through the first 20 rounds of DES exactly the same as did crypt(). It then went on to run 5 rounds of DES on the remaining 8 chars (null-extended if less than 8 given) and concatenated the two strings to give the final hash. It turned out that DEC had reduced the security by at least 20% over crypt() and by more if one considers that dictionary search of password suffices ran five times faster than dictionary search on crypt() itself. They had replaced that security with a small amount of ineffectual obscurity.
Paul
Re:Grsecurity is for real (Score:1, Interesting)
>>from Linux kernel code to unmentioned blackhat
>>companies
If Brad has publically stated this, I wouldn't even touch his code in a second... Some countries fear using Microsoft products cause they fear there might be a backdoor, yet your telling me this individual is exploiting this on Linux? Mind you, you are posting as an AC, so maybe your just full of shit...
"That which is beautiful is moral. That is all, nothing more."
-- Gustave Flaubert, French novelist (1821-1880)