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

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 [openbsd.org] has implemented security [openbsd.org] 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 [theaimsgroup.com]:

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?

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

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: [e-mail]
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... [theaimsgroup.com]

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

[Anonymous Coward]

Grsecurity is not a set of patches. It's one patch. (One command to apply it.) Not much of a work.

The Grsecurity has also superior learning mechanisms for ACLs. It is really easy to get the most constraining set of ACLs with which the software still works for the system. Take a look at the process.

Grsecurity also has lot's of things that can be ACL'ed. What OpenBSD has is good mkay but it has had several security problems such as constant canaries in the kernel. (Fixed couple months ago.) It's a lot simpler actually. (But yes, working.)

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

[Homology]

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

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?

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?

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

Actually

[bonch]

Actually, it's a pointless comparison because Linux is just a kernel while Windows is a kernel (and a very good one), a HAL, a GUI subsystem, various system libraries, various applications that use them, etc.

I will say, however, that taking the average monthly vulnerabilities for any given Linux distro + kernel and comparing to Windows yields surprising results. About the same ore more vulnerabilities exist in Linux distro apps than on a typical Windows installation. See http://www.linuxsecurity.com/advisories [linuxsecurity.com] and compare for yourself.

The point is that we're all humans making software, so we're all prone to the same mistakes. Both systems are inherently insecure to the same degree, but Windows is used so much more that holes are widely reported.

You complain when trolls pop up and say "Ha ha!" to Linux vulnerabilities, but look at a Windows vulnerability article on Slashdot sometime and you'll find 90% of the discussion follows those very lines. Some people genuinely enjoy Microsoft technology and use it daily, so it's a little healthy schadenfreude when it's pointed out that, hey, Linux isn't the 100% flawless Golden Warrior it's made out to be. It's a dangerous mindset to have anyway--it makes you overlook things. Which seems to be the case in this LWN article.

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 [debian.org], 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 [nsa.gov] 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.

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 [microsoft.com] 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 [microsoft.com].
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 [microsoft.com]. If the client doesn't explicitly log on, he gets an anonmyous [microsoft.com] 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 [microsoft.com] 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 [microsoft.com] page about SMB authentication; it's written for NT3.x.
See also Security Subsystem Architecture [microsoft.com], although for Win2k, the architecture really hasn't changed that much; just expanded to include Active Directory.

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