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.

Pated to save a click. As usual Linus doesn't mince his words :)

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?

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.

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.

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.

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.

It doesn't seem like they are very good at code review or testing, for example:

https://twitter.com/marcan42/status/724745886794833920?lang=...

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

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.

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.

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.

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.

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

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?

Out of curiosity, how did you determine that someone was trying to exploit you? And that the kernel crash was due to an attack?

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.

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

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.

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.

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.

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.

Prove it.

As I've said script kiddies probably fail at exploiting this but if you have valuable infrastructure to maintain and you've got someone talented or bored on the other side or even inside your network i.e. university networks where you can't reboot everything every other day it's not unrealistic.

First up, nearly half of this years priv esc bugs in Linux so far are specific to Android (and most of those involve things like nvidia drivers). That's serious, but not "somebody can get root on my server" serious.

Another handful of them are specific to some driver, some kernel module, or some kernel feature, that would only be used on a subset of systems. Still bad, but it does mean that at any given time, even systems running theoretically exploitable systems often won't be because the feature needed to exploit it isn't turned on and can only be turned on by root. For example, one of the high scoring vulnerabilities requires a user or process with CAP_NET_RAW capability. That has to be granted by root, and would presumably only be granted to trusted users and processes.

But, others are pretty scary and would be exploitable in a lot of cases. It's a reminder to stay on top of updates. And, also a reminder that the kernel is a huge surface area for attacks. It sometimes seems like a miracle that any of this stuff works at all.

It prevented every single kernel exploit that came out during that time.