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

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

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

[IamTheRealMike]

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

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

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

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?