I see grsecurity in the web hosting industry a lot. Tons of people have bought their snake oil (and major players in the shared hosting and multi-tenant hosting space are proponents of grsec).
I've always been uncomfortable with it, even though there are a handful of good ideas in there. Why would I trust something that isn't allowed to go through the normal quality vetting process as the rest of the kernel?
I don't think it's at all reasonable to refer to Grsecurity as "snake oil". I think it was a mistake to say that, and you should probably retract and apologize.
You don't have to like Grsecurity, or recommend it. Lots of people don't. But you're a professional working in this field and what you've written on this thread doesn't meet that standard.
Care to refute? We've got quotes from Linus himself in this thread that show a belief that their products do not provide value.
I'd say that while Linus is generally inflammatory, he's also generally correct. I don't know that what SwellJoe has said is any worse. Do you believe Linus should retract and apologize as well?
This request is genuine - you're a well respected voice in the security world, and I'd be curious to see your take on this. I've never seen sufficient evidence to prove the grsecurity claims that they make the kernel more secure in a meaningful way, and if there are outside experts that have evidence of this, I think it would be beneficial to share that evidence.
Regardless of that, however, I do think it's damaging to support a company that is flagrantly violating the GPL. It's not a license I particularly care for, as more of a BSD/MIT type person, but I do think that if you make money as a derivative work of something, you should damn well follow the license of the work you're deriving from.
I think you're missing the point here. It's not helped by the way Linus has expressed himself here. The truth is that there's a fundamental philosophical disagreement here: Linus prioritises not breaking userland, GR security doesn't. Their patches are "crap" because they're large and not in the correct style, not because they don't achieve what they set out to do. Sometimes people take subsets of those patches, clean them up and get them put into the kernel, which is the source of GRS's accusations of "stealing".
The short version is that GR Security have personalities and behaviors very like Linus' own. There's value in GRS, and a fair amount of bad behaviour, but let's be frank, the same's true of Linux.
> Sometimes people take subsets of those patches, clean them up and get them put into the kernel, which is the source of GRS's accusations of "stealing".
This is insane. If their argument had any legal merit, it is because of a bug in gpl and we should patch it. Just based on the accusation of theft, without knowing anything else about them or anything else, I can safely say they're scum bags and no I don't have a Fields medal but I don't retract it.
I do think Linus should have adopted "or later" a long time ago but that's a different discussion.
And when called out on this, they simply block the people saying it.
I'd personally be very skeptical of any security company that values their own tolerance for dealing with people telling them their code sucks over finding out that their code sucks and fixing it. And a lack of good code review and testing is of huge import when it comes to security, at least in my opinion.
Then there's also their weird crusade against (e)BPF without any supporting evidence beyond "It adds more features so that's more attack surface and thus shouldn't ever be added or attempted and we don't believe anyone involved could ever make it secure so there."
> We've got quotes from Linus himself in this thread that show a belief that their products do not provide value.
All I see is a link to some message where Linus calls these patches pure garbage. There's very little context, and the only borderline technical issue he points out is that grsecurity breaks things. If that is the message you're referring to, it only shows that the grsecurity patches are not aligned with Linus' values. That's a very different thing than the belief that they provide no value.
We know more about Linus' values, based on this old quote:
> I think the OpenBSD crowd is a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them.
So, for example, if your values place performance and compatibility with old (proprietary..) binaries above all else, then a patch that degrades performance and breaks compatibility with old binaries may as well be "pure garbage."
Yet, a lot of people are willing to sacrifice some performance & compatibility for improved security. Now whether grsecurity does that adequately is a debate I do not wish to take part in.
>If that is the message you're referring to, it only shows that the grsecurity patches are not aligned with Linus' values.
The thread is actually someone asking if it's worth taking a look at how grsecurity handles a large stack guard gap to get ideas for implementation in the kernel. Linus then responds saying to not bother with them.
It's a pretty clear condemnation of them in general, not just their shitty patch submission process.
Linus' take on security patches is a highly debated topic. Not only with the grsec guys, but all other people working in netsec. That does not mean Linus is always wrong (though imo he often is regarding that topic) nor that grsec is great of course.
You'd know better than I would, though I'm not inclined to apologize. I will use more mildly negative language henceforth, however.
My problems with Grsecurity are, in order of importance:
- This whole licensing thing. I like the GPL. I publish much of my software under the GPL. I want the GPL to be a real thing that we all respect and abide by. When someone breaks that social contract, we all lose.
- The lack of effort to work with the rest of the kernel community. They've got this huge stack of patches (and it is huge), they're selling it to a bunch of folks (some of whom probably know enough to be making security decisions, many of whom probably don't), and yet they don't really seem interested in being a member of the OSS community.
- There's a recurring theme (even before now, I've heard this argument) of people asserting that someone attacked their server, and, because they had grsec, it crashed instead of allowing the attacker to exploit the system. As though that's not a successful attack in and of itself. The quality of grsecurity code has been called into question by more than one kernel dev, including Linus.
- There's some misleading marketing going on somewhere. I happen to work in the industry sort of parallel to grsecurity. We have a handful of the same customers, there's some overlap in the systems we see and the ones they exist on. For whatever reason, our users who have grsecurity on their systems are the most poorly informed about how the security features of a Linux system fit together (and they think all of them come from grsecurity, even though usually it's none of the ones we're talking about or helping them with). I don't know if grsecurity folks are misleading their customers, or people are just filling in the blanks with where security comes from (obviously it's the security product they paid money for, rather than the kernel itself which was free and thus obviously worthless). It's like the Fox News of kernel patches, somehow messing with it makes people less knowledgeable about the security of their systems.
It's a personal pet peeve, I guess. But, there are, as I said, good ideas in grsecurity. I wish they'd go through the usual process of getting things into the kernel. As it is, they've got a cool research kernel that's unfortunately been pushed into production on some of the most dangerous systems out there (shared hosting and multi-tenancy systems that have barely trusted users and frequently run poorly maintained web apps that often expose the system to untrusted code).
I'm rambling a bit here, but my point is, I won't call it snake oil anymore, but I'm probably not gonna shower it with praise, either. The folks building it are clearly very smart. I really don't mean to denigrate their skills, their experience, or even the software they've built. I just wish they worked with the kernel community more, and I wish whoever is spreading around myths about kernel security and how grsec interacts with it would stop doing so.
> The lack of effort to work with the rest of the kernel community.
It's not lack of effort. There's blame to be had on both sides, but for a long time (more than a decade) the kernel community stonewalled any security ideas because they just didn't care about mitigating unknown vulnerabilities. They thought it fine to just fix them after they're found, and have everyone recompile.
There's a few articles on this relationship, but it's not as one-sided as you seem to be saying.
The fact that it took order of a decade (I can't be bothered to look up actual years right now) between grsec adding non-executable pages to mainline Linux doing it is embarrassing.
The linux kernel community could and should have re-invented non-executable pages during that time, if nothing else, like when OpenBSD reinvented it and pretended they were first.
I don't expect or ask you to praise it, but in software security, "snake oil" has a particular meaning that absolutely does not apply to Grsecurity.
Grsecurity might not be appropriate for the kinds of systems you deploy --- or, even, in your professional judgement, for any production system!
But "snake oil" refers to security products that don't do anything, and that are built in bad faith to bilk users out of their money. Grsecurity clearly isn't that, as anyone can see by Googling (just for instance) "RAP RIP ROP."
I should probably just refrain from participating in esoteric security topics from now on; it's above my pay grade. I'll stick to complaining about their licensing.
What about grsecurity do you consider to be snake oil?
A couple of times the grsecurity patch has prevented a machine of mine being exploited - the first time the exploit didn't work at all and the second grsecurity added enough protection that the kernel crashed and rebooted.
I consider both Brad and PaX Team to be very clever people (though you could easily argue I'm biased as I use the grsecurity patch, confirmation bias and all that)
The fact the kernel protection project are trying to take grsecurity and get it implemented into the kernel also suggests to me that it's not snake oil.
A couple of times the grsecurity patch has prevented a machine of mine being exploited - the first time the exploit didn't work at all and the second grsecurity added enough protection that the kernel crashed and rebooted.
Out of curiosity, how did you determine that someone was trying to exploit you? And that the kernel crash was due to an attack?
Both times friends of mine with shell accounts tried the last kiddy exploit.
First time they fessed up they'd tried it and said it didn't work, the second time apologised for causing the box to reboot.
Since crashes (especially segfaults) are often indications of an exploitable vulnerability causing the kernel to crash isn't exactly a good thing. It prevented one attack, caused a (probably short) denial of service, and may be further exploitable.
As I said, I think there are some good ideas in grsecurity. But, I am mistrustful of something built by a small team without outside vetting, particularly when it comes to security sensitive code.
The "snake oil" part is that somewhere along the way, a significant segment of a huge industry has been convinced that features that are standard in the current Linux kernel are only possible with grsecurity. We get feature requests all the time that begin with, "You should integrate grsecurity so that we can do X"...when X is already possible with the mainline kernel. I don't know if it is the grsec marketing folks or the folks who integrate grsec into their products, but somebody is misleading the general public about what is and isn't in mainline.
Unfortunately "small team" as in giving us their private time, describes lots of security-relevant software we're using every day. GPG was a recent example in need of funding.
I'm not sure what you mean by no vetting though. There's quite a bit of discussion related to grsec. A small team is a small team - it doesn't need to be a corporation to work. It may actually work well because it's a small team.
That's true. But, many people I trust have had pretty negative things to say about Grsecurity. I'm not well-versed enough in the subject area to make a good decision on my own, but if I have to choose who to listen to about Linux kernel issues and it comes down to Linus or some other dudes, I'm listening to Linus.
But, that's orthogonal to the problem of small, poorly funded, teams ending up being responsible for major infrastructure, including major security infrastructure. The kernel is one of the few really important pieces that isn't understaffed or underfunded. So, generally, I just trust that the kernel team and my distro of choice are doing good things and use what they give me.
I'm not afraid to patch the kernel, and I've even maintained custom kernel modules and kernel packages in the past, but I'm not going to slap random stuff into my kernel just because a company that profits from it tells me it's better, especially when Linus says it is "garbage" (his word, not mine).
I mean, I don't care what you call it. There are good things in grsecurity. But, I'd like to see them go through the normal kernel development process before I trust them.
I've always been uncomfortable with it, even though there are a handful of good ideas in there. Why would I trust something that isn't allowed to go through the normal quality vetting process as the rest of the kernel?