8 ms·

I stopped taking Grsec seriously a long time ago. Grsec makes the kernel more secure by breaking it. The code in their patches does not meet the standards/style

I stopped taking Grsec seriously a long time ago. Grsec makes the kernel more secure by breaking it. The code in their patches does not meet the standards/style of the Linux kernel and has in fact been criticized by third parties for just not being good code. I could make a crappy patch that breaks networking and market it as a security feature because it "prevents intrusion", but it also breaks useful features. They appear to have some kind of internet defense force or something defending them at every turn but it's become more and more apparent lately that grsec is a low-quality code base maintained by programmer(s) with bad attitudes and superiority complexes. I've been in tech for quite some time and never encountered anyone using grsec patches. They do a really good job of marketing their product on tech forums though.

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 ago
  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. So I'm curious as to why you think it is?
  - SwellJoe 9y ago
    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.
    - 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 ago
        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).
- deleted 9y ago
  [deleted]
- clackityhack 9y ago
  On 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 ago
    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.
- tptacek 9y ago
  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.
  - cthalupa 9y ago
    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.
    - ibotty 9y ago
      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.
    - 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 ago
  Snake 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 ago
  Snake oil? Being that you couldn't be further off the mark, you really should not be speaking on this topic.
viraptor 9y ago
It reads like you don't believe their patches make a difference. They may have bad attitude and weird personal approach to software distribution, but their code does what it should do. Sure, you'll have bugs sometimes like with everything, but I think it's worth acknowledging that they do some serious research and published it for a really long time. Their RBAC existed before LSMs were cool and accessible. Their layers of protection were always explicitly listed as options you can toggle yourself. Their newer ideas like RAP are pretty much the best thing available in terms of ROP protection. And now that recent grsec is not available anymore, people do implement the same mechanisms piece by piece upstream. I find it disappointing people describe grsec as quoted "prevents intrusion". It's not some dodgy internet protection bundle for windows. You can read exactly what it does and why. If it breaks something, you can either identify which part is incompatible with your system and disable it, or you can report it as a bug. You're not forced to use it of course. You could write something that breaks the kernel and market it, but no, you could not write grsec level of code most likely.
tayo42 9y ago
Has there been a serious hack that was caused by a kernel exploit? It seems like the hacks I hear about are caused by something higher up. But I don't exactly keep up with exploits. How viable is a kernel exploit to actually do something? I would think by the time an attacked could actually use one they have already gotten pretty far.
- nisa 9y ago
  If you are on shared hosting or any kind of machines that depends on the kernel to enforce permissions any kernel hole means ability to rootkit the whole thing, set up persistence and access data from root or other users. There is stuff like kerberos tokens for admins, everyting secret in /etc like ldap passwords, private keys or ability to change read-only code to setup a backdoor. You can tap the admin if he uses the machine for SSH hopping - grab backups... the list is endless. Linux is full of local root exploits and while most script-kiddies just exploit your WordPress plugin and mine some coins or setup a DDoS script that works until someone notice it, having root and a rootkit on machines is probably the goal of any serious intruder - especially if it's servers on organisations and stuff like that. It also means depeding on the exploit that you can escape Docker, LXC or even KVM/QEMU - rarely but it has been done.
  - bcoates 9y ago
    I'm honestly surprised that people still bother with multi-user access control. Defense in depth only works if the defenses are actually manned, and it's been pretty clear that nobody's been taking linux local escalation seriously for a very long time. Shared-hosting is, in practice, a high-trust environment, and trying to patch your way around that sounds like the snakeoil logic of Windows security products.
    - nisa 9y ago
      Shared hosting is high trust? You are basically one stolen credit card and 5 minutes away from giving strangers SSH access to a host with lot's of customers that often process sensitive data. Might be true that it's not that important for the cloud crowd where you just use an instance for everything but that that's expensive and not the reality outside of certain bubbles and in the end the problem is just invible to you because Google or Amazon are tightening their hypervisors for you. Lot's of Hadoop/HPC clusters or university desktops depend on this stuff. With everyone moving to Docker and Containers the kernel is the only thing that prevents an intruder from owning the host or the cluster - it's a shame that this is not taken seriously - however they still assign CVEs for it. On a modern cluster node you have software defined networking - having root on a node also means access to different VLANs and stuff like that - most distribued applications just blindly trust anything inside their internal network are a pain the secure (try setting up Hadoop with Kerberos, it's not exactly click&play). A normal setup gives you a SSH key and instant shell on every machine in the cluster. Also most machines are identical so if you own one, you most probably have the means to own all. You can also get all the configuration management data as root. It's for sure not a barrier you should use as your last stand but it's something that should be as hard as possible to overcome. Just giving up and saying who cares only makes the job for future intruders easier.
clackityhack 9y ago
Your opinion is clearly borne of sheer ignorance. > Grsec makes the kernel more secure by breaking it. No, their patch set includes many different exploit mitigation techniques, and reduction of the attack surface. > I could make a crappy patch that breaks networking and market it as a security feature because it "prevents intrusion" You could, but this has nothing to do with how grsecurity works.
- aeleos 9y ago
  The issue he is referring to is the grsecurity has a history of allowing breaking patches, allowing bad code, attempting to upstream patches in chunks without splitting them up to make the process easier, and then complaining that their patches are being ignored.
_wldu 9y ago
Linus on grsecurity: https://www.spinics.net/lists/kernel/msg2540934.html https://www.spinics.net/lists/kernel/msg2540934.html
- corford 9y ago
  "Their approach has always been 'we don't care if we break anything, we'll just claim it's because we're extra secure'. The thing is a joke, and they are clowns. When they started talking about people taking advantage of them, I stopped trying to be polite about their bullshit. Their patches are pure garbage. Linus" Pated to save a click. As usual Linus doesn't mince his words :)
knorker 9y ago
I used grsec for a decade, both professionally and privately. It prevented every single kernel exploit that came out during that time.

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 ago
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. So I'm curious as to why you think it is?
- SwellJoe 9y ago
  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.
  - 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 ago
      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).
deleted 9y ago
[deleted]
clackityhack 9y ago
On 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 ago
  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.
tptacek 9y ago
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.
- cthalupa 9y ago
  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.
  - ibotty 9y ago
    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.
  - 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 ago
Snake 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 ago
Snake oil? Being that you couldn't be further off the mark, you really should not be speaking on this topic.

viraptor 9y ago

It reads like you don't believe their patches make a difference. They may have bad attitude and weird personal approach to software distribution, but their code does what it should do. Sure, you'll have bugs sometimes like with everything, but I think it's worth acknowledging that they do some serious research and published it for a really long time. Their RBAC existed before LSMs were cool and accessible. Their layers of protection were always explicitly listed as options you can toggle yourself. Their newer ideas like RAP are pretty much the best thing available in terms of ROP protection. And now that recent grsec is not available anymore, people do implement the same mechanisms piece by piece upstream. I find it disappointing people describe grsec as quoted "prevents intrusion". It's not some dodgy internet protection bundle for windows. You can read exactly what it does and why. If it breaks something, you can either identify which part is incompatible with your system and disable it, or you can report it as a bug. You're not forced to use it of course. You could write something that breaks the kernel and market it, but no, you could not write grsec level of code most likely.

tayo42 9y ago

Has there been a serious hack that was caused by a kernel exploit? It seems like the hacks I hear about are caused by something higher up. But I don't exactly keep up with exploits. How viable is a kernel exploit to actually do something? I would think by the time an attacked could actually use one they have already gotten pretty far.

nisa 9y ago
If you are on shared hosting or any kind of machines that depends on the kernel to enforce permissions any kernel hole means ability to rootkit the whole thing, set up persistence and access data from root or other users. There is stuff like kerberos tokens for admins, everyting secret in /etc like ldap passwords, private keys or ability to change read-only code to setup a backdoor. You can tap the admin if he uses the machine for SSH hopping - grab backups... the list is endless. Linux is full of local root exploits and while most script-kiddies just exploit your WordPress plugin and mine some coins or setup a DDoS script that works until someone notice it, having root and a rootkit on machines is probably the goal of any serious intruder - especially if it's servers on organisations and stuff like that. It also means depeding on the exploit that you can escape Docker, LXC or even KVM/QEMU - rarely but it has been done.
- bcoates 9y ago
  I'm honestly surprised that people still bother with multi-user access control. Defense in depth only works if the defenses are actually manned, and it's been pretty clear that nobody's been taking linux local escalation seriously for a very long time. Shared-hosting is, in practice, a high-trust environment, and trying to patch your way around that sounds like the snakeoil logic of Windows security products.
  - nisa 9y ago
    Shared hosting is high trust? You are basically one stolen credit card and 5 minutes away from giving strangers SSH access to a host with lot's of customers that often process sensitive data. Might be true that it's not that important for the cloud crowd where you just use an instance for everything but that that's expensive and not the reality outside of certain bubbles and in the end the problem is just invible to you because Google or Amazon are tightening their hypervisors for you. Lot's of Hadoop/HPC clusters or university desktops depend on this stuff. With everyone moving to Docker and Containers the kernel is the only thing that prevents an intruder from owning the host or the cluster - it's a shame that this is not taken seriously - however they still assign CVEs for it. On a modern cluster node you have software defined networking - having root on a node also means access to different VLANs and stuff like that - most distribued applications just blindly trust anything inside their internal network are a pain the secure (try setting up Hadoop with Kerberos, it's not exactly click&play). A normal setup gives you a SSH key and instant shell on every machine in the cluster. Also most machines are identical so if you own one, you most probably have the means to own all. You can also get all the configuration management data as root. It's for sure not a barrier you should use as your last stand but it's something that should be as hard as possible to overcome. Just giving up and saying who cares only makes the job for future intruders easier.

clackityhack 9y ago

Your opinion is clearly borne of sheer ignorance. > Grsec makes the kernel more secure by breaking it. No, their patch set includes many different exploit mitigation techniques, and reduction of the attack surface. > I could make a crappy patch that breaks networking and market it as a security feature because it "prevents intrusion" You could, but this has nothing to do with how grsecurity works.

aeleos 9y ago
The issue he is referring to is the grsecurity has a history of allowing breaking patches, allowing bad code, attempting to upstream patches in chunks without splitting them up to make the process easier, and then complaining that their patches are being ignored.

_wldu 9y ago

Linus on grsecurity: https://www.spinics.net/lists/kernel/msg2540934.html https://www.spinics.net/lists/kernel/msg2540934.html

corford 9y ago
"Their approach has always been 'we don't care if we break anything, we'll just claim it's because we're extra secure'. The thing is a joke, and they are clowns. When they started talking about people taking advantage of them, I stopped trying to be polite about their bullshit. Their patches are pure garbage. Linus" Pated to save a click. As usual Linus doesn't mince his words :)

knorker 9y ago

I used grsec for a decade, both professionally and privately. It prevented every single kernel exploit that came out during that time.