what's about 2.6.8 (2.6.8.1)

[Terra Inc]

when? =)

[perlionex]

It's a bit tough to have grsec out when pax isn't even yet.

http://pax.grsecurity.net/

[Terra Inc]

but grsec for 2.4.27 is out, although pax only for 2.4.26 =)

[perlionex]

but grsec for 2.4.27 is out, although pax only for 2.4.26 =)

you got me there!

i guess it's probably 2.6.x tree's still undergoing a lot of changes; in the past, you could apply a, say, 2.4.25 grsec patch to the 2.4.26 kernel and get away with it without much problem; but if you've tried doing that for grsec for 2.6.7 to 2.6.8.1 kernel, you'll know things are quite different. so i guess it'll take a bit longer to get that up and running...

[goal]

* [email protected] [040808 13:51]:
> If you're going to use 2.6.7, please also apply fixes for the numerous
> security bugs present in that kernel. Due to significant changes in the
> "stable" 2.6 tree that break much of PaX, a 2.6.8 patch may not be
> coming soon.

[Danytgv18]

grsec for 2.6.8.1 kernel is not ready yet? RSBAC works for kernel 2.6.8.1

[spender]

Why post here then? You should use RSBAC, since clearly by using RSBAC there is no need for PaX or grsecurity.

[Danytgv18]

Yes,but Grsec is much better.I like it much more.RSBAC is not so ... easy,is very difficult,grsec have much more options than RSBAC,so... I wait until grsec 2.6.8 is ready

[Anlar]

Since the question pops up every once in a while I will drop in a few lines.

The 2.6 kernel series and grsecurity has several problems.

1. The 2.6 kernel series is new and quite volatile (it keeps changing slightly on every release, even on the "important" areas such as memory management). Thus it has not been audited properly for security. How could it be when it changes constantly? Most likely it has a greater number of security related bugs in the same amount of lines of code than the more stable 2.4 kernel series.

That makes the paranoid people still be scared about the 2.6 kernel series. Hey, some are still at 2.0 for just the reason! The sad thing is that they are in a way correct with their thinking.

However, you got to evaluate what security means to you. For some people it is enough that all the known bugs have been fixed and the lame kiddies can't break in. That constitutes 99.9% of the security breaches and even most of the people who call themselves "security professional" or hackers/crackers/whatever. You got to keep in mind that though 2.4 has most likely considerably less bugs it too has still them.

Though the Grsecurity addresses a few of the general threat areas there is nothing it can do to keep you safe from the scenario that someone really wants to break in and finds his own previously publicly unknown exploits.

That's why the focus is still at 2.4 kernel series. I might want to partially disagree with the Grsecurity developers with their stance though. The 2.6 is already coming at .10 and the kernel developers seem to be slowly reaching satisfying solutions for the functions in the kernel. There is still lots of movement going on and will be but it should start slowing down.

Furthermore if you are just running a desktop and not some mission critical server, why the hell not use 2.6 series? Security isn't about being absolutely correct on technical matters. It's about realizing threats and keeping them controlled. Most of the security related thinking in real world isn't technology related since in the war between bomb and shield the bomb has always won and will always do so. Just keep an eye on the known bugs and you are safe from 99.9% of the threats. Most likely if you are using some desktop oriented distribution the largest problems are elsewhere anyways. (Passwords, services, basic stuff like that, unpatched userland stuff perhaps)

You got to realize it is not easy. Grsecurity should be better available and supported for 2.6 kernel series but it isn't - at least yet.

2. Burden. You guys really realize what happens when they change the memory management functions and stuff like that on the kernel? At worst it means the PAX (PAX is the hardest part usually) has to be pretty much rewritten for that kernel. What happens one month later? Well, the same again. The Grsecurity/PAX is pretty much on the shoulders of 2 people that just are not enough. Especially when they are not being sponsored properly.

3. Grsecurity/PAX developers are great guys. They've been researching their area for years. They really do know it, trust me. They are however highly technical people and outside the technological context they are like ducks at Sahara. They pretty much lack all the social skills. Their arrogance and just the fact that they are usually correct arises opposition from the other developers.

The upstream kernel developers could take on some small patches and gradually most of the stuff. It would lead into better integration and perhaps the new kernel releases would not always break everything. There is though some opposition for such security features on the Linux kernel for various reasons. First of all it makes the kernel more complex and harder to maintain. Kernel developers also aren't that paranoid about the security features. In their view a patched standard system is pretty good already.

Some features are slowly getting in though. Exec_shield is slowly getting into the kernel I heard. Why SELinux and Exec_shield but not Grsecurity/PAX? Grsecurity is technically plain superior. SELinux is incoherent mess, then there is the LSM security bugs and exec_shield just isn't very effective (it works against a quite limited range of type of attacks etc).

However Grsecurity isn't as well productizated. It isn't backed up with a sense of support that Selinux/Exec_shield enjoy (though Exec_shield is afaik born from the very early page_exec or something like that) and simply the guys can't pull the correct strings.

Instead of fixing the problems at Selinux/Exec_shield and contributing they are choosing destructive routes such as whining and being pompus assholes. Sorry guys, but your contribution when done properly could be just awesome. Rationalized properly the guys' input would be most likely very appreciated.

For the same reasons they can't find real good sponsors. Anyone sponsoring them should lend them a hard helping hand and sedate the guys to get the thing actually work. Furthermore they would like harshly put the sponsors to pay for what they are doing. But they aren't doing correct things from the potential sponsors' views.

4. They got to pretty much start ripping away the kernel included memory management etc related stuff to get their own stuff working. It's an extra burden. Some versions are harder, some easier to get working. Such happens when there are extensive branches. The developers are pretty much pissed off with the stuff they got to "put up with". And it's not getting any easier I bet. I bet Spender might know better though.

----

I would pull of the strings and let the monster die. Grsecurity is nice but it has absolutely no sustainable future with the current way things are being done with. If you Spender can't admit that to yourself, sheesh..

[spender]

I would pull of the strings and let the monster die.

Good. Let me know when you've finished. If you don't like the situation, why haven't you personally done something about it? Otherwise you're simply being a "whining and pompous asshole."

-Brad

[spender]

While you're at it, tell me if grsec and PaX were in the kernel, if someone made a change to the VM that broke PaX, who would have to fix it?

If I have to get a fix in or correct someone else's "fix" do you think it will be easier to deal with a bunch of bureaucracy if grsec is in the kernel?

Can you point me to a group of kernel developers that are eager to throw out LSM and remove the broken NX functionality from RedHat? We can't even get RedHat to fix blatant security holes in their software. Do you really think they'll agree to this? Better yet, have you asked them?

But I guess you've thought about this all much more than I have, since you have such strong opinions.

[Anlar]

[quote="spender"]While you're at it, tell me if grsec and PaX were in the kernel, if someone made a change to the VM that broke PaX, who would have to fix it?

If I have to get a fix in or correct someone else's "fix" do you think it will be easier to deal with a bunch of bureaucracy if grsec is in the kernel?

Can you point me to a group of kernel developers that are eager to throw out LSM and remove the broken NX functionality from RedHat? We can't even get RedHat to fix blatant security holes in their software. Do you really think they'll agree to this? Better yet, have you asked them?

But I guess you've thought about this all much more than I have, since you have such strong opinions.[/quote]

There we go on again. Not a simple good point taken, just attack mode. One was just trying to suggest a better more co-operative model of improving Linux systems but it was taken as a sheer insult. And I wasn't even insulting (look, no basist jokes or anything). (I admit being an asshole at this moment. Not being would serve no point. Your attitude would perhaps be constructive. Or could.)

First of all, I am not a developer, why should I do something? You are the developer. You have the know-how. "Stop whining then?" That's thinking like if judges should be criminals to be able to judge them.

You seem to have thought a lot about how broken NX and some other things are, have been for a while. Why haven't done anything, beats me. The route with more bureaucracy would still be more productive for the total user masses today.

You imho pretty much made my point there.

[spender]

I asked several legitimate questions that still deserve answers. How can you claim to know what is best for me and the users if you can't even answer my few questions?

Your post *is* insulting and *is* arrogant because it's equivalent to a student that doesn't know anything about math trying to tell the math professor how to do his job. I can assure you, I have thought about this much more than you have, and if there were an easier way to do things that didn't compromise the goals of the project, and thus would be better for the users, I would be doing it right now.

It's your mistake to think that I ignored your post and was simply attacking you. It's just that your arguments are uninformed. You are not a sponsor so you cannot speak for the viewpoints of my sponsors.

I am a developer. I am not an advertiser or advocate. My focus is on security, not on making grsecurity popular. Generally in projects that have supportive communities, the community handles the advocacy. So yes, it is your obligation to see that these changes are made. My time is better spent elsewhere. For instance, while you were busy typing, I was committing several changes to both grsecurity trees and making a grsec-only patch for 2.6.9 so that a 2.6.9 patch can be quickly released as soon as the PaX port is complete (which will be soon).

-Brad