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."

Comments

Time for (even) better security?

[moz25]

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.

Re:Time for (even) better security?

[Wudbaer]

Hey, great argument ! So Linux doesn't even need to be stable, you just can string together several boxes because it is sooo cheap. Yeah right.

Re:Time for (even) better security?

[thogard]

I've always found an uptime of more than a few months tends to mean that sysadmin skills are seriously lacking. Sure a few systems can run for years but most real world systems need patches and changes and proper testing means a "reboot test" just to verify that changes to the live system are in non volatile. If the system requirements for a system have changed in the last year and the box hasn't had a full test, then there is a major problem.

Re:Time for (even) better security?

[DjReagan]

If you can't work out ifyour changes are volatile or not without rebooting the system then I suggest that it might be YOUR sysadmin skills that are lacking.

Personally, I make sure I know the answers to that sort of question before ANY changes are made to my production systems.

Re:Time for (even) better security?

[EasyTarget]

Humm, and how do you react when you come in to the office after a long weekend and find the server is locked in a panic cycle, because some change you made months ago means it won't boot properly? No doubt you blame everybody; developers, documenters, compilers, colleagues, god etc.. But the real reason it failed is because you did not test properly.

Personally, I know my servers can survive a reboot, because I test them for that. If I make any serious change that may affect startup I assume it will fail, and then set out to prove myself wrong.

PS: I wish I did not have to.

Re:Time for (even) better security?

[PacoTaco]

I've always found an uptime of more than a few months tends to mean that sysadmin skills are seriously lacking.

Interesting.

Re:Time for (even) better security?

[krymsin01]

I may have missed the point of the GP post, but what I got from it is that if you have a couple servers runing linux, with load balancing between them, you can take on of them offline, patch it the kernel, recompile, then do the other. I don't think anything was said about not being stable.

Re:Time for (even) better security?

[router]

He probably has a pre-production environment. That's what you do when you want to know how your changes will affect production. That way you don't fsck with production. I think he stated that above. Some of us don't fsck around. If you wanted to be really paranoid, you would reboot first to make sure nobody else changed anything that would fail a reboot, then make your changes, test to be sure a reboot is really necessary, then reboot again anyway to satisfy your paranoia. In pre-prod. But that's if you're paranoid. And work with a team. And have pre-prod. Maybe I'm crazy.

andy

Re:Time for (even) better security?

[Anonymous Coward]

Personally, I know my servers can survive a reboot, because I test them for that. If I make any serious change that may affect startup I assume it will fail, and then set out to prove myself wrong.

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.

Re:Time for (even) better security?

[Wudbaer]

I know that it was meant that way, and I admit that it basically is right. What was irking me about the GP post was the general mindset: "Why do we need improved security and/or longer patch cycles if we just can use a workaround." Similar sentiments come up in other posts in this thread "Oh, it's just a DoS attack, there are worse things" "Oh, don't you have a firewall" etc.pp.

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:Time for (even) better security?

[jedidiah]

Ebay was running solaris and ended up going down in a ball of flames because they were too obtstinant to apply the vendor recommended updates. This isn't a problem limited to Linux.

Re:Time for (even) better security?

[Xenophon Fenderson,]

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.

That's not the point. I am getting ready to force my Unix admins to patch their boxes on a more frequent basis than "yearly", and they are already screaming bloody murder. I am sick and tired of our Unix boxes getting rooted because some admin wants 365+ days of uptime and can't be bothered to test and install a kernel patch that fixes some important hole. That there is NO scheduled maintenance to start is an even larger problem that I'll rant about in a different post.

And by the way, other Unix systems have capabilities, MAC labels, etc., and you know how most admins implement security on their systems? Every one of the Unix support team knows the root password, and the application support people use setuid scripts to administer their software, like they were doing in 1985. Capabilities, labels, and friends are extremely difficult to implement, and these features cannot save you from the one time a tired kernel programmer accidentally performs an unbounded input or forgets to check a counter. You will always need to patch your kernel (and reboot) in order to maintain operational security. Period. End of discussion.

And if your only availability measurements are along the lines of

for i in `cat hosts`; do ssh root@"$i" uptime >> uptime.report; done

please get a clue: Availability doesn't include all of those times when your users tries to access a rooted system (even though the system is "up"), and it isn't a bad thing to schedule maintenance windows and notify the users and take the system down for patches or upgrades. In fact, I would much rather do so in a controlled fashion, as I can have backups made and documentation updated and I can take my time to do things correctly because I had time to test everything beforehand. Versus a 50+ hour nightmare/marathon starting with the pages from the instrusion detection system (or worse, from someone else's IT security department) at the wee hours of (if you are lucky) Saturday morning.

So don't complain to me about lousy uptimes. Because when your server gets hacked because of a kernel bug patched three months ago, and you didn't apply the update because "my uptime counter will get reset" (i.e. you are lazy), I have to clean up your mess: Investigating the attack, determining the extent of the intrusion, validating the backups, etc.

BAH. Rant mode off. I will spare you a discussion of the proper engineering processes that help to lessen (but not eliminate) the risk of security-related software flaws.

Re:Time for (even) better security?

[router]

Ok, I may have misread the parent, since I took it to mean he reboots after any change that had a remote chance of causing problems with reboots. Of course you test reboots...and failover. But those are scheduled tests of reboot and failover, not added onto other changes. I maybe read as he reboots trivially, which is avoidable by having pre-prod. I did have a disclaimer on there, I might be crazy....*cackle*

andy

Re:Time for (even) better security?

[tomhudson]

Oh, come on. Did you read the whole thing? This was over the holiday period, people are human. Additionally, Linus and M.M. were (as the writer noted) busy with other changes to the kernel.

Listen to this and decide if it sounds more like a kid whining because they didn't get their way:

Between December 15th and today, Linus has committed many changes to
the kernel. Between January 2nd and today, Andrew Morton has committed
several changes to the kernel. 3 weeks is a sufficient amount of time
to be able to expect even a reply about a given vulnerability. A patch
for the vulnerability was attached to the mails, and in the PaX team's
mails, a working exploit as well. Private notification of
vulnerabilities is a privilege, and when that privilege is abused by not
responding promptly, it deserves to be revoked.

The guy who wrote this is a self-righteous prick.

Read this response:

OTOH, sending patches of any sort to Linus or A.M. if you are not one of their trusted senders is not very effective. Sending it to the security teams of Debian, Fedora or SuSE would probably have been a much faster path.

Re:Time for (even) better security?

[moz25]

Don't worry, the last time any of my boxes was rooted was on the 10th of June 2002. I remember that day and all the trouble well enough to keep my systems up to date :-)

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:Time for (even) better security?

[thogard]

Its basic system theory. I can't know all the interactions between all the systems so I can't account for everything. The easy test is to schedule some downtime and tell the system to reboot. If all goes to plan the system is back up in 90 seconds with most server (or 5 minutes for a cisco router).

At work we have 2 nearly identical systems that can each cope with the entire load and they don't need to talk to each other except for non real time things like end of month reports. The reboot test is a great way to keep from getting bitten by stupid things like a change in openssh's dealing with /dev/random where a change in the startup sequence means there isn't quite enough random state in the system to prevent a deadlock.

How do you know that the disk label is still working? Most OS's won't let you read it (since its cached). There are many parts of modern hardware that are essential to booting but can't be accessed outside of the reset sequence. There are things like
flash bios that you can't test from a live system and that perpetual problem with hard disks of "will it wake up next time?"

I've got a few outstanding bugs with cisco because their NAT/PAT stuff doesn't come up quite the same way as when its entered so the only way to know if a config is going to "stick" is to bring the thing up from a full reset state.

I agree that a sysadmin should be able to come up with a full deadlock state diagram for the system but when that graph has more than 1000 nodes on it, the only sure way is a 'halt' and hit the reset switch but even that doesn't test a full start from a power off state.

Re:Time for (even) better security?

[arkanes]

This sort of thing happens a lot in large open source projects. Joe Blow finds some (quite likely perfectly valid) bug or flaw or whatever, spends a lot of time creating and testing a patch, submits it and... nothing. It's ignored. Joe Blow gets very upset, occasionaly posts flames, takes his code and goes home, etc, etc. It's a valid problem. You have to look at it from the side of the project maintainers too, though - they don't know this guy, they don't know his code, and they don't have time to audit it for correctness. You need people willing to handle triage for patches and pass them up the chain. This isn't an especially fun or thankful job (although it's critically neccesary) so a lot of projects lack these sort of resources. However, the linux kernel DOES have these resources, and this guy should know better than to be all whiny that his personal patches aren't being fast-tracked.

Re:Time for (even) better security?

[naden]

I've always found an uptime of more than a few months tends to mean that sysadmin skills are seriously lacking.

Interesting

I gave up modding for this.

thogard: BURN !!!! :)

Re:Time for (even) better security?

[DjReagan]

I don't come into the office after a long weekend to find the server is locked in a panic cycle. The reason why is that I *do* test properly. This involves quite a fair bit of preparation and planning and testing long before any changes even touch my production servers.

This does not involve rebooting production servers after any and all changes "just in case" which is what the original poster was indicating when he said that an uptime of more than a couple of months indicated poor skills.

If the change is one that would reasonably have some affect on startup procedures, then startup is tested. It is tested first in our development environment, then in our staging and disaster-recovery environments. By this stage I will know weather my changes are volatile or not, and I will know what needs to be done to ensure the change works correctly. I don't need to reboot my production servers to answer that question.

Re:Time for (even) better security?

[silas_moeckel]

Ah guess you have never worked in someplace where there are no acceptable scedualed maitnence windows with outage.

Preproduction is key here generaly working of of split mirrors and the like to insure things are exact replica's. It's just an issue of procedure if you dont have good procedure here you wotn have good tests. So I would differ on the nigh-on impractical part as matches hardware and a good mirror is the same thing :)

Course I may be biased I work with exact matching boxes we I can bring up a server on any of the hardware at any time in case of failure.

Re:Time for (even) better security?

[JohnFluxx]

Actually I think it's more like him mailing bill gates directly.

Re:Time for (even) better security?

[Sunspire]

Because you cannot make any assumptions about the attack vector. Say there's a local vulnerability found in the kernel that can give you privilege escalation. It's no problem right, since you don't allow remote logins, so you're not going to patch it. Wrong.

Next time there's a small hole in Apache that for instance allows execution as the apache or nobody users, that local kernel security hole will come back to bite you in the ass and lead to your box being rooted.

It doesn't even have to be a Apache hole. Say some little bit of user supplied input is being used in some chrooted or otherwise jailed context, perhaps you're generating a PS or PDF file in some temp directory on the fly. Again that little security mistake you've made combined with the local privilege escalation flaw you didn't patch will stretch the hole to goatse.cx proportions.

Unless your machine is unplugged from the net, patch that kernel. Seriously, it's like insurance, a little pain every now and then so that when the shit hits the fan you'll hopefully live through it.

Re:Time for (even) better security?

[tomhudson]

Agreed. All he had to do was subscribe to the LKML (linux kernel mailing list), and he would have known that you can't just send a patch in out of the blue.

He's a hypocrite to complain about how linux needs to be organized to receive patches, when he is himself ignoring the protocols already in place to deal with the problem.

Imagine what would happen if linus had to personally look at every email about the kernel - nothing wold get done.

Interesting point of view

[ChrisJones]

but I don't really see much counterpoint. Anyone have URLs for where this has been discussed in some more depth?

Re:Interesting point of view

[IamTheRealMike]

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 ...)

Re:Interesting point of view

[10Ghz]

Andrew Morton said:

An unprivileged local user can DoS a Linux box to death with malloc and
memset, so the RLIMIT_MEMLOCK bug isn't particularly exceptional. All the
others require root anyway.

I'll pass this on to appropriate people, see if we can get this all fixed
up, thanks.

Re:Interesting point of view

[R.Caley]

[that there are easier ways is] a pretty specious argument

No, an important security rule of thumb. Don't waste effort fixing the holes which no one would need to exploit because you are wide open in other places.

Eg, would you worry about people being able to drill into your safe if the safe had no door?

There are special cases where you might (front of safe visible to trusted people 24/7 or something), but generally speaking, priorities are important.

Re:Interesting point of view

[tomstdenis]

quotas. If working and properly setup can "contain" such people.

Tom

Re:Interesting point of view

[LurkerXXX]

How about having that procedure nicely spelled out on an official website rather than just having to google for it and hoping the article you find has both real and current information? It's not hard. The BSD guys do it.

The Linux guys failed more on the netiquette than the PaX guys. They failed to put forward a real working contact list. Security guys don't like to trust random results from google. How do you know your sending it to the 'real' security person? I can't put the blame on them for this mess at all. Imho, one should never ever ever fail to provide an easy to find current working contact list for exploits.

Kind of an interesting contrast

[aendeuryu]

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?

So it begins.

[Anonymous Coward]

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!

Re:So it begins.

[LurkerXXX]

Bring new development? You mean like OpenSSH, PF, CARP, etc?

Yeah, those OPENBSD'ers are stuck in the mud and never think about new development.

Re:So it begins.

[SunFan]

You mean like OpenSSH, PF, CARP, etc?

I wonder how many Linux geeks use OpenSSH to tunnel X Windows from their PC over the network and think "Wow, Linux is the bomb, Linux does this cool stuff." Probably too many.

Re:FUD

[millahtime]

You are refering to 'decent' linux setups. How many people have what you would refer to as a 'decent' linux setup. Windows could have a 'decent' security setup but most people don't go there. Linux needs the security to rock out of the box if it is to continue it's mainstream grouth without running into the problems windows has.

Gee, maybe I should run Novell...

[filesiteguy]

...oh, wait - I AM running Novell Linux. Oops. Um, I should tehn run and hide in a closet?
Maybe I should implement security measures and have a good backup system?
Nah!
This kind of reminds me about all the people telling me you could die while driving a car - no s---, Sherlock! Use common sense.

Don't be an idiot.

[Anonymous Coward]

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.

Here it comes

[Tangwei]

For years now people have been carrying the Linux flag due to the fact that its "more secure then windows"... guess what people.. time for being an unknown, unpopular OS is at hand... welcome to being known.

Re:Here it comes

[I confirm I'm not a]

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:Here it comes

[I confirm I'm not a]

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).

Re:Here it comes

[I confirm I'm not a]

Not at all. I'm saying keep it in proportion: "one swallow does not a summer make", and a limited number of bugs do not an insecure system make. Truth is, no system is - or can be - totally secure unless you encase it in steel and disconnect it from the 'net.

Windows is insecure. Linux is also insecure. So's Trusted Solaris. It's a question of degrees: how far are you prepared to trust Windows with different levels of secure data? How far would you trust Linux? Solaris? For my part, I'd use Windows. Hell, I do use Windows, daily. I even like it. I just wouldn't use it on, say, an eCommerce server. I wouldn't use Solaris to rip CDs, either, but that's no slur aganist Solaris.

Re:linux vs ???

[Homology]

ok it has some problems that need to be worked out... but what are the alternatives... is this story meant to cause people to say "OMG M$ was right better contact my local sales rep" or is the community slacking???

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.

Maybe it's time...

[Jace of Fuse!]

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.

Re:Maybe it's time...

[I confirm I'm not a]

I pretty much agree with you, but... (!)

Having the source to an OS doesn't make it more secure if you don't read (or understand) every line of it. (my emphaisis)

Having the source available for anyone to read can lead to the OS (app, library, whatever) being more secure. Assuming that a wide-enough group of people do actually read the code. I'm confident that this happens with Linux, the *BSDs, etc.

Most people tend to equate OSS with secure, I'd guess, because security-through-obscurity is largely a false promise, and we recall that many-eyes-make-bugs-shallow. Both concepts that appeal to the type of geeks who are interested in security ;)

Re:Maybe it's time...

[Anonymous Coward]

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.

Everybody acknowledges that. But that doesn't mean that operating systems are all alike. Linux - out of the box - is far more secure than Windows, and far less secure than OpenBSD.

My Windows XP machine is solid and secure.

Really? The last time I tried to secure a Windows machine, Microsoft had a list of 200-odd things to change, including obscure registry entries. Furthermore, the box was practically useless, as half the user applications insisted on being able to write to privileged directories or just plain run as Administrator.

Sure, in theory you can secure both machines quite well - ignoring the open vs closed tendencies of course. But in practice, it's a nightmare trying to get Windows to sane security settings and also work properly.

Why people think OSS is automatically more secure is something I never have really understood.

Nobody thinks that. You have misunderstood the argument that the OSS development model by its nature tends to result in more secure software.

Re:Maybe it's time...

[ChrisJones]

"a neglected unix is far safer than..."

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:Maybe it's time...

[Xilman]

Unixen, and any other OS for that matter, aren't going to have boneheaded mistakes engineered into the system by design. You primarily have to worry about MISTAKES rather than the things that Microsoft engineers intentionally put into a system.

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

Grsecurity is for real

[Anonymous Coward]

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.

Re:Grsecurity is for real

[conteXXt]

"Brad was forced to sell new vulnerabilities from Linux kernel code to unmentioned blackhat companies."

I guess this is a good reason to trust them?

Re:Grsecurity is for real

[diegocgteleline.es]

"Exec shield" was not copied from PAX, it'd quite hard since the developer of "exec shield" (Ingo Molnar) admits that Pax covers more cases than PAX.

It'd be nice if someone would ask the PAX developers why they modified their test suite to fail under exec shield. Run the pax test suite in a exec shield kernel and all the vulnerability simulations will succeed. That's not why exec shield is bad, it's because the test suite disables exec shield on purpose (you can disable exec shield, that's a feature)

BTW, exec shield is not going in the kernel. Exec shield != "amd NX bit". The amd nx bit support has already gone in the kernel, but I'm not surprised at all that no grsecurity patch is going to the kernel. Grsecurity developers have NEVER submitted their patches to mainstream, they haven't even tried it, they haven't listened to constructive criticism. That's why grsecurity is not in the kernel and LSM is. They have just sit back saying "our stuff is better, use it" without even caring. There're lots of projects that have go poop because of that attitude. Remember the guy who rewrote the whole building infrastructure which never go in mainline? He updated his stuff regularly and critized Linus for not getting his obviosly better alternative. He didn't listen to Linus when he said "ok, just split it in small, individual parts" (like everybody else does) "and I'll merge it". When some other guy started to fix the available building system, the "Better stuff" went poop. Same will happen with LSM. LSM is bad? Well, what will happen if the developers decide to fix it, where will go grsecurity?

I very much prefer a good developers/maintainer than a bad one, so I'll choose LSM at any time even if it is technically inferior. A good maintainer means that in the future he can rewrite his stuff if it's not good enought. That's much better than some guys who sit back in their mailing lists saying "our stuff is better"

Re:Grsecurity is for real

[arkanes]

...Brad was forced to sell new vulnerabilities from Linux kernel code to unmentioned blackhat companies.

So basically what you're saying is that these are the sort of guys who're so morally broken that they wouldn't pass even the most superficial of background checks for a sensitive position, which is no doubt why they need to get money by selling to blackhats rather than getting a real job in computer security. Basically, exactly the opposite of the sort of person you'd want to trust as a contributor security information and patches. Thanks, I'll remember to disregard anything I see from these morally challenged turdballs in the future.

distro with grsecurity

[UnderAttack]

Are there any distros out that include GRSecurity? I use it on all my 2.4 kernel boxes with great success and just started using it on production 2.6 systems. Overall, I find it to be very stable, and a very worth while extra layer of protection even without using the role based ACLs.

Re:Microsoft?

[TheRaven64]

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.

Ok, so where are the patches?

[menscher]

It's now been several days since the uselib() kernel exploit was posted and reports started to trickle in that it works. But there is no patch from the RedHat (or any other vendor, from what I've seen). What gives? Anyone got the inside scoop on what these vendors are saying on vendor-sec?

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:Ok, so where are the patches?

[inode_buddha]

Yes, there are patches for it. Check out the -ac branch, or read up on it at kerneltrap.org and follow the links.

Re:Ok, so where are the patches?

[IamTheRealMike]

It was fixed in Linus' upstream kernel either yesterday or the day before, I forget which.

Re:Ok, so where are the patches?

[Stephen Williams]

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

It's all too political

[m50d]

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?

Start over, basing on OpenBSD for a change...

[ivi]

Long-time shell-provider SDF used Linux ...until they got hacked into.

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...

Re:Start over, basing on OpenBSD for a change...

[Homology]

Secure Dog Hosting is using OpenBSD for all it's infrastructure. SecDog has been no 1 on Netcraft for longest uptime.

Wrong Recipient?

[z0ink]

According to LWN the advisories were sent to Linus Torvalds and Andrew Morton themselves. I'll admit that I don't know jack about the inner-workings of Linux Kernel development, but one would think that something of that nature would go out to the person in charge of security related issues or even out to the distributions to get a fix circulating. I could be dead wrong and maybe Linus is just the only guy running the show and decides when he'll spend some of his time patching the kernel. This also seems as a sort of public way of the author expressing his disdain towards Linux security and as a sort of publicity for his own system. Maybe I'm just too much of a cynic, but things aren't all they are cracked up to be. Please note that I am not saying that there isn't some sort of responsibility there, but that this seems overly hostile.

Waaah! 3 weeks without an answer!

[Tsu Dho Nimh]

From the grsecurity page: "my personal gripe is that for 3 weeks not a single acknowledgement arrived in my mailbox, i don't think that's the way the chief developers are supposed to handle security issues (however small or irrelevant they may have been in this case - it takes a one liner to tell us so)."

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:
Please see http://www.kernel.org/pub/linux/docs/lkml/reportin g-bugs.html if you want to report a Linux kernel bug.

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.

Re:Microsoft?

[Anonymous Coward]

Fine grain control != more secure.

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.

Patches are here

[inode_buddha]

>Hi all,
>Is there a patch to uselib() bug ->
>> http://www.isec.pl/vulnerabilities/isec-0021-useli b.txt ?

Date: Sun, 09 Jan 2005 17:28:35 +0100
From: Henrik Persson
To: Breno Silva Pinto
Cc: linux-kernel@vger.kernel.org
Subject: Re: patch to uselib()

It's patched in 2.4.29-rc1 and 2.6.10-ac6. A patch for 2.4 can also be found here:
http://marc.theaimsgroup.com/?l=linux-kerne l&m=110 514006004261&w=2

and for 2.6:
http://marc.theaimsgroup.com/?l=linux-kernel &m=110 512844202355&w=2

Browsing the archives usually gives you alot of answers, you know. ;)

----------------
Cut-n-pasted from the LKML

wow...

[advocate_one]

his beef is because he sent Linus an email on Dec 15th...

> Let me begin by giving you a timeline:
>
> December 15th: I send Linus a mail with a subject line of
> "RLIMIT_MEMLOCK bypass with locked stack"
> December 27th: The PaX team sends Linus a mail with a subject line of
> "2.6.9+ mlockall/expand_down DoS by unprivileged users"
> January 2nd: The PaX team resends the previous mail to Linux and Andrew
> Morton
>
> Between December 15th and today, Linus has committed many changes to
> the kernel. Between January 2nd and today, Andrew Morton has committed
> several changes to the kernel. 3 weeks is a sufficient amount of time
> to be able to expect even a reply about a given vulnerability. A patch
> for the vulnerability was attached to the mails, and in the PaX team's
> mails, a working exploit as well. Private notification of
> vulnerabilities is a privilege, and when that privilege is abused by not
> responding promptly, it deserves to be revoked.

and he's made the assumption that Linus has actually seen the email??? After no reply for a day, he should have resent the email and kept resending it until Linus had sent him an acknowlegement... bloody stupid to send a critical email and assume receipt

Re:wow...

[Anonymous Coward]

yes, spender had all the reasons to expect Linus to see that email because he (Linus) had actually answered him a few days before which actually resulted in a commit (http://linux.bkbits.net:8080/linux-2.6/cset@41bc9 00azV2y9j9FSjVLwmow0n5mmQ).

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:Waaah! 3 weeks without an answer!

[R.Caley]

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.

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!

Re:OK, if not Fedora Core..

[Anonymous Coward]

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.

broken development process

[Malor]

From a security perspective, the current Linux development model is a nightmare. Introducing new features into the 'stable' codeline is not how to reduce bugs and problems.

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:

Not all 2.6.x kernels will be good; but if we do releases every 1 or 2 weeks, some of them *will* be good. The problem with the -rc releases is that we try to predict in advance which releases in advance will be stable, and we don't seem to be able to do a good job of that. If we do a release every week, my guess is that at least 1 in 3 releases will turn out to be stable enough for most purposes. But we won't know until after 2 or 3 days which releases will be the good ones.

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!

Re:broken development process

[iabervon]

With respect to needing to switch versions to a kernel that is different in unexpected ways, it's exactly the same if you're running a 2.4 kernel.

There are actually improvements with 2.6: the distros have been invited to take over 2.6.x.y series, so that if they're going to be backporting patches, they can contribute this effort back to the community. In 2.4, the distros carry so many patches that you'd have an easier time backporting from the latest 2.4 vanilla kernel than from a distro kernel with the same nominal version. They have so many patches because they feel the need to add functionality in their stable series.

Also, Alan Cox is maintaining a tree of "really stable" kernels, where he takes only bugfixes from the current work and adds them to the base version he's using. I haven't determined if he's planning to continue 2.6.9-ac indefinitely, or if he's going to only release 2.6.10-ac kernels once he judges 2.6.10-ac to be sufficiently tested.

The real issue is that Linus is currently in charge of releasing the stable versions. He's really good at identifying what should go into the stable series, from the perspective of guiding development, but he doesn't have the discipline to identify a completely-working version and call that 2.6.x. My prediction is that, in accordance with the ManagementStyle document, he will eventually decide that people complain about his release descisions, and therefore he should get somebody else (probably Alan Cox) to do that.

As for development causing security problems, there has yet to be a 2.6 security hole in code that was added during 2.6. In general, new code is checked for all known patterns of bugs (almost all security holes fall into some pattern) and bad practices before being accepted. On occasion, a bug is found which is part of a new pattern, and future code with the same sort of bug will be caught, but existing code with that bug is not necessarily identified. This means that bugs are generally in code that hasn't been changed in a long time, not code which has been changed recently. In fact, there have often been bugs found in old versions which had already been eliminated unknowingly from new versions by people writing replacement code using improved techniques.

For example, the recent hole was in code written ten years ago to facilitate the switch from a.out to ELF. The hole was a race condition due to changes made several years ago in the requirements of common code.

You're basically right, but...

[Moraelin]

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.

Re:You're basically right, but...

[Fulcrum of Evil]

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.

In all fairness, MS Bob was never intended for corporate use. It can be forgiven for not being very secure, as the only person with access to the console is likely Melinda herself (the last active Bob user).

Re:You're basically right, but...

[Blakey Rat]

Ok, I'm going to create a new rule:

Anybody who brings up Microsoft Bob in a Linux vs. Windows discussion not only instantly ends the discussion, but loses whatever their point of view is. Blakey Rat's Law.

Holy shit, you just complained that a product that was on the market for maybe a year and a half a *decade* ago, and intended for children and neophytes on a single-user machine, has bad security because it doesn't enforce passwords strictly? Are you serious?

Are you so divorced from common everyday experience that you:
1) Are still obsessed over Microsoft Bob a decade after it failed and everybody else has forgotten it?
2) Think enough other people are still obsessed over Microsoft Bob that using it in an argument would support your point?
3) That a security hole in Microsoft Bob is even a valid argument?

The saddest part is that I agree with your basic argument. Security on computers, until about Windows 2000, was completely crappy across the board. It wasn't until the 21st century that people really started looking at it and figuring out ways to improve it... and I think that people are still looking in the wrong direction. (We know how to secure computers, more or less, let's work on social engineering.)

Oh well, at least people like you keep Slashdot interesting... but, man, get a grip on reality and hang on for dear life.

Re:You're basically right, but...

[Blakey Rat]

Whoosh, watch my entire point go flying right over your head.

"MS people" don't need to defend the company based on Microsoft Bob because Microsoft Bob was sold for about a year a decade ago, then was dropped, and nobody has given a second thought about it since then.

That would be like criticizing Ford because their cars made in 1935 lacked seatbelts. "Ford is the worst auto-maker because their 1935 sedan had no seatbelts, they were trying to kill their users!" Does that make any sense as an argument? No.

Is Bob insecure? Sure. Does it matter? No, of course not! NOBODY USES IT! Just like nobody drives a 1935 Ford sedan on a daily basis. It doesn't matter. It's a pointless, and stupid, argument. Microsoft Bob can't be used as a hacking tool because NOBODY USES MICROSOFT BOB!

You're just as deluded as the poster I replied to. Join the rest of us here in 2005, where nobody has even seen Microsoft Bob in 8 years and few people have even heard of it. Nobody gives a shit about Microsoft Bob. Few people did when it was on store shelves, and nobody does now... except a few deluded people on Slashdot.

Re:You're basically right, but...

[Foolhardy]

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.

Where did you get that silly idea? NT has always used impersonation of the client's account to detirmine access.

1. The client connects to the file server with the SMB protocol to start a session and to establish the client's identity in the form of a token.
Authentication of the client's identity is handled by a LSA authentication module such as samsrv.dll for the local user database, msv1_0.dll for an NTLM domain or kerberos.dll for a kerberos domain (2000 or later). The security token is generated by one of these packages and passed along to the SMB server at impersonation level. If the client doesn't explicitly log on, he gets an anonmyous token. In any case, the session must have a security token associated with it to proceed.

2. Before accessing anything on behalf of the client, the thread servicing the request impersonates the client using their token. Instead of using the process's access level for access, the client's token is used. At the kernel level.

See this page about SMB authentication; it's written for NT3.x.
See also Security Subsystem Architecture, although for Win2k, the architecture really hasn't changed that much; just expanded to include Active Directory.

Unless you rip out what you don't need.

[khasim]

If you're running a server, then you should rip out everything you don't need.

If you aren't running it, you don't need to patch it.

Which only leaves the security/bug fixes for what you do run. Do I worry about a "reboot test" after I upgrade perl? No. Why should I?

On my Debian systems, the only patch that requires a reboot is a kernel upgrade.

A "reboot test" might still be a good idea, in the 0.0001% of non-kernel situations where it would show a software problem ... but why bother if there wasn't a problem on the test box?

I'd rather not reboot my boxes because that seems to be when the hardware fails. Much as most light bulbs that blow seem to blow when you turn them on.

Re:Unless you rip out what you don't need.

[arkanes]

Well, the most obvious reason is that you've got startup scripts that require perl, and the new version may have some sort of syntatic change or other issue that'll break your scripts. In fact, this was quite a problem with Python and some older version of Redhat (7.3 or something? I forget)

Re:Microsoft?

[TheRaven64]

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.

You are confusing Mandatory Access Control (which Windows and SELinux both have), and Rôle Based Access Control (which SELinux has). Mandatory Access Control simply means that objects have access control associated with which is defined by system policies, rather than by users. In Windows NT, members of the Administrator group can set MAC policies. In FreeBSD (and TrustedBSD), they can be set by the root user.

Rôle base access control means that permissions can be assigned to users in certain rôles. This allows users to have different permissions depending on their current mode of operation. This is what you explained in your post.

Fine grained access control at a kernel level is always preferable to coarse-grained access control (with the possible exception of performance-critical systems), since it can always be wrapped by coarse-grained interfaces at a higher level if simplicity is required.

same feeling with S-ATA

[davFr]

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?

That word doesn't mean what you think it means.

[rjh]

The kernel developers are, in my opinion, shirking their single most fundamental duty

Just a few questions:

1. How much have you paid Linus, Alan Cox, Andrew Morton, et. al., directly?
2. Did they make any promises to you about the reliability or stability of the kernel?
3. Take a look at the GPL, particularly that explicit disclaimer of all warranties. Did Linus send you a certified mail letter in which he waived that clause for you?
4. Did you get certified mail waivers of that clause from all the other kernel developers?
5. I'm sorry, I didn't hear you the first time--how much did you pay Linus, himself, directly?
6. Does Linus give you binaries only of the kernel, and thus make you dependent on him?
7. Does Linus give you source code, and thus give you the option of auditing code yourself?
8. Have you done your own code audit?

Just a few simple questions, really. Because before you go about saying that Linus, or any other kernel developer, or any other Free Software developer, has a duty to you, I'd like for you to know what duty means.

Duty means a debt is owed.

So--as a result of the community giving you, at no cost, generous license to literally hundreds of millions of dollars of intellectual property... they owe you something? Because they gave you a gift?

I don't know where this false sense of entitlement within the community arose, but I really hope it goes away soon. You aren't entitled to anything. You aren't entitled to the sweat of my brow, the labor of my hands, the product of my mind--but when I release something under a free license, I give you those things. I say "here, have something; I made this. I want to give it to you."

And what are you doing?

Looking the gift horse in the mouth.

Quick, everyone RELAX

[jayloden]

OK, everyone, take a deep breath, calm down, and say it with me: "Linux is not dead. This is not the death of Linux"

It's going to take more than a couple of articles to bring about the demise of Linux. There are definite reponsibilities and issues that need to be addressed in Linux, as there always will be in any project of any size. Let's all just support our OS, and make sure that we make it known that it's important to us that these issues are addressed. A few negative articles are not going to kill OSS, and Linux has a way of weathering problems. Relax, and support the developers so they can get on with fixing the problem(s).

-Jay

Re:True, all politics

[10Ghz]

The worst politics of all is the Linus'es stance against driver ABIs. That's one reason behind the device support is still slumbering.

I bet that Linux has alot better device-support out of the box than Windows XP or Windows Server 2003 has. Windows relies on third-party drivers that may or may not work, whereas in Linux they are already in the Kernel, where they receive more attention than third-party drivers would receive. And that's thanks to Linus's stance on drive ABI's. Without that, we would have a kernel that had minimal device-support and which needed flaky third-party drivers just to get a functional system. And those drivers would only work on x86-systems. Why would the OEM's spend time developing driver for PPC or Sparc, since those are niche-systems? But since they are in the kernel, they work on more exotic architectures as well.

Favorite Quote

[radoni]

But it is important to understand that one can't just pick up the "Bat Phone" and have Linus or Andrew on the other end. Those days are gone.
- sbergman27, [http://lwn.net/Articles/118251/]

These PaX "security experts" whine and complain like script kiddies. No wonder.

I think the real point is made that distro volunteers and employees are more likely to implement a patchset for security reasons. Also, this is in the best intrests of the community, by limiting the amount of direct communication forced upon our Overlord and Savior, and also because most of us are using a distro. If a distro has a security patchset and the vanilla kernel is left with holes, surely someone will take notice and go through the proper channels, doing all that hard contacting work for you.

New development model to blame?

[bakreule]

I've always thought the new kernel development model was a bad idea. Instead of creating a new 2.7 branch for new code under development and letting the 2.6 branch stablize, the powers that be decided to put everything in 2.6. The downside of this is that there is no "stable" kernel as each new revision contains new "unstable" code and fixes for older versions. I'm not sure what the upside is.

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.

Right on!

[Oestergaard]

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 :)

Re:Right on!

[Oestergaard]

No they haven't, and actually the VM seems to be pretty good.

True, 2.4 was an absolute nightmare up to around 2.4.16 as you said. The difference from then to now is, as I see it, that there were a few well focused attempts at solving that one huge problem, and then there was the general bugfixing going on meanwhile. Today, you have some general bugfixing going on, but all while that is happening, lots and lots of new features are added - core parts are touched in places where they (evidently) do not like to be touched, so to speak.

Sure, nobody (in their right mind) expected 2.6.0 to be bug free or even close. But I at least had an expectation that a stable 2.6 was the goal and the direction in which development would be going.

Again, I'm sure it will eventually. But until it does, for some uses 2.6 is just unusable.

(all is not bad; for example, my mother is using 2.6 on her desktop, and the hot-plugging works great - a lot of very good things are in 2.6, but for us people who need machines to have uptimes of more than 8 hours under heavy load, it's just not really good enough).

Re:Bugtraq rulez.

[Alan Cox]

Nobody contacted the vendors that I can find, or the official security reporting list for the kernel, or CERT, or any other such body as would be good practice. Apparently they lobbed a private mail at Andrew and it got lost.

Re:Patches are in -ac7

[duffbeer703]

The thing that is "retarded" is the fact that a huge security hole can slip through the cracks if Linus doesn't check his voluminous email.

Linux isn't just a hobby toy anymore. If Linus is holding on to things too tightly, he's doing himself and the community a disservice.

Re:True, all politics

[Kjella]

I bet that Linux has alot better device-support out of the box than Windows XP or Windows Server 2003 has.

Absotively.

Windows relies on third-party drivers that may or may not work, whereas in Linux they are already in the Kernel, where they receive more attention than third-party drivers would receive.

More attention than from Microsoft? Certainly. More attention from the people selling the hardware in question? I would hope not, for the company making it's sake. The fact of the matter is that it is critical to their business, and that most windows drivers work, and work well. It doesn't matter if you're OEM or retial, if you make doohickeys for Dell, and customers complain to Dell, Dell will complain to you.

When you think it over though, that makes it better not to have closed source drivers for Linux. Why? Because Linux just isn't critical to their business. Having half-assed buggy, obsolete drivers that the developers can't fix would make the situation worse, not better. Not having a stable ABI is the lesser of two evils, but it is a drawback, not a strength.

You must understand that to users, putting in a CD to install the drivers is a non-issue (particularly if the task involves installing something *gasp* inside the case). If I thought Linux could get the same level of support as a Windows driver, I would recommend he did. But if Linux was that important, they couldn't afford not to support it anyway. So by the time you have the momentum to make an ABI work, you don't need it. Ironic, isn't it?

Actual Concern

[kg4gyt]

One has to remember that the linux exploits are much harder to actually take advantage of than the windows exploits. Linux security holes, although serious, one must first gain access to the physical terminal, then have the time needed to actually use the exploit, as opposed to writing a webpage or powerpoint file that someone merely has to open to become a zombie. Linux needs fixing at times, however the security holes are in comparison, not as serious as those Windows users encounter almost daily.

Leaving the Door open for someone else

[tacocat]

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:OK, if not Fedora Core..

[SunFan]

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*.

Yes, I'm shocked that you assume people have no life and can maintain a set of patches for their kernel just like you do. Sure, with Linux, I'm free to fork it, but I'm also free to write the next great epic novel. I leave you waiting in suspense, I guess, for my novel to appear in the book stores (I hope you are patient!).

Re:Grsecurity is for real?

[adric]

While I agree that security issues must be taken seriously, I feel the need to point out that Brad isn't exactly a paragon of virtue himself. In the past he's threatened to withhold information on vulnerabilities in competing projects, in order to make his own project more attractive... a bit of googling will turn up other examples.

Personally, I switched from grsecurity to SELinux shortly after the incident linked above. While Brad may in fact be quite skilled, I've simply lost trust in him and, by extension, his project.

Bzzt... get off the high horse

[Moraelin]

Nobody gives a fuck about MS Bob itself, but it's a glaring example of the fact that MS didn't give a shit about security to start with. It extends to all their products as well.

Want non-Bob examples?

How about the NT file security I mentioned in the same post? That _is_ a corporate product, and was pushed as a corporate product. That design is so cretinous, idiotic, lobotomized and clueless, that there aren't enough words to that effect in the dictionary to express it.

How about the password protection for MS Office documents? It could be "cracked" in milliseconds flat. In fact, at least one company selling programs that allowed people to unprotect their files went on record to say that they built a delay in their program to look like there was _some_ effort involved. And yes, those were and still are pitched at businesses, not at clueless home users. (See the "Small Business Edition" variant thereof.)

How about Hotmail? That wasn't a decade ago, and a you could access anyone else's mail on it without even much effort involved.

How about the endless stream of buffer overflow exploits in _all_ MS products, because MS cared more about benchmarks than about security? Yay, their products were a few milliseconds faster, at the cost of being insecure.

Etc, etc, etc. As I've said, the list really is a mile long.

So you can get off the high horse, you know. It's not about Bob itself. It's just a clear cut case of MS not giving a shit about security in _any_ of their products until very recently.

Re:Patches are in -ac7

[LurkerXXX]

The people aviable are documented and if you don't know a simple IRC session would point it out for you.

Absolutely friggin brilliant. Because we all know no one ever fakes their idenity in IRC. You sir are a genius!

Re:No holes in default install due to no services

[Homology]

that's bullcrap that's propogated by people too lazy to even check. For the record sshd, fingerd, identd, and sendmail are enabled by default

Time with some corrections for a default OpenBSD install ;-) First fingerd is not started, and has not for quite some time. Sendmail is started, but only listen on localhost. From OpenBSD 3.6 you get the question during install if you want to enable sshd. Via inetd is the following enabled : ident, comsat (mail submission), daytime and time. syslog is enabled, but don't listen on UDP by default.