5 ms·
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
by SwellJoe 9y ago
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?
- muppetman 9y agoWhat 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. So I'm curious as to why you think it is?
- SwellJoe 9y agoAs 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.
- viraptor 9y ago> built by a small team without outside vetting 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.
- SwellJoe 9y agoThat'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).
- sillysaurus3 9y agoA 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?
- muppetman 9y agoBoth 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.
- SAI_Peregrinus 9y agoSince 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.
- ryanlol 9y agoGrsec doesn't magically make bugs go away, it just makes many of them unexploitable, or at least very hard to exploit.
- cthalupa 9y agoThe second situation certainly sounds like a successful exploitation to me. A denial of service attack is still a successful exploit.
- deleted 9y ago[deleted]
- clackityhack 9y agoOn what basis do you claim that grsecurity is "snake oil"? I will await your comprehensive technical rebuttal of its feature set and implementation, which you have no doubt carefully analyzed.
- SwellJoe 9y agoI 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.
- tptacek 9y agoI 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.
- cthalupa 9y agoCare 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.
- ibotty 9y agoLinus' 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.
- clarry 9y ago> 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.
- knorker 9y agoSnake oil? I ran grsec for a decade and it prevented every single kernel exploit that came out during that time. All of them.
- lawnchair_larry 9y agoSnake oil? Being that you couldn't be further off the mark, you really should not be speaking on this topic.