11 ms·
Background: the "kernel self protection project" (KSSP) recently upstreamed the Grsecurity/PAX reference counting implementation which prevents a certain class
by lima 9y ago
Background: the "kernel self protection project" (KSSP) recently upstreamed the Grsecurity/PAX reference counting implementation which prevents a certain class of security bugs from being exploited.
Grsecurity is a security hardening patchset for Linux that makes deliberate trade-offs in favor of security, sacrificing availability if necessary. This, aside from the political issue, is the main reasons why it's hard to upstream it. Linus has called some of their mitigations "insane" before precisely for that reason. Grsecurity will rather terminate userland programs or, in some rare cases, panic the kernel if it finds itself in an undefined state. This is exactly what you want if you care about security, but it's not a trade-off everyone is happy with (including Linus).
Unfortunately, Grsecurity/PAX is not (and probably won't ever be) involved in the KSSP project, and the KSSP developers do not understand the code nearly as well as the Grsecurity team does. This lead to a situation where the new code caused a crash that they weren't able to fix in time, so they disabled the feature in the last minute.
I've been using Grsecurity for years until they stopped making it publicly available, and I remember many bugs that were uncovered by PAX_REFCOUNT and yes, occasionally panicked the kernel where a vanilla kernel would run just fine. They usually found and fixed those within hours.
Grsecurity/PAX have invented many of the modern exploitation mitigations, probably second to none. Some have even been implemented in hardware. Their expertise in building modern defenses is astonishing (their latest invention, the control flow integrity mechanism RAP, is a work of art).
Linux could be the most secure kernel, instead, it's fallen way behind Windows - which has much better defenses than Linux nowadays thanks to Microsoft's ongoing battle with rootkit writers. Go figure.
If the large companies who use Linux really want to improve kernel security, they need to work with Grsecurity and not against them. It's beyond me how this isn't happening already.
- amelius 9y ago> Grsecurity will rather terminate userland programs or, in some rare cases, panic the kernel if it finds itself in an undefined state. This is exactly what you want if you care about security, but it's not a trade-off everyone is happy with (including Linus). I'd also like my kernel to halt whenever an assertion does not hold, for the sake of keeping my sanity; not just for security. Why would you not want this?
- jhasse 9y agoFor the cases where it was a false-positive.
- otabdeveloper1 9y agoA.k.a. 99.9999% of the time.
- payne92 9y agoFor the same reason people drive with their “check engine” light on: It’s frequently better to have a working system (i.e. “I’m late for work”), than to chase an indicator that may not represent a real problem (an actual security intrusion).
- Slavius 9y agoI can't think of single useful piece of software nowdays that is exposed to public and can't run in active-active load balanced or clustered scenario. If your kernel/system/userland-app misbehaves it simply needs to be shut down, reported and examined. It might have been some random memory block the last time your app made an buffer overflow, but it could as well be the stack pointer next time...
- mjw1007 9y agoWeb browsers are, for practical purposes, exposed to the public. Linux doesn't run only on servers.
- Slavius 9y agoSo what happens when your browser crashes? I experience that on a regular basis. Id' rather have my browser crash/killed instead of slowly overwriting my filesystem buffers or corrupting my stack pointer... Other than that browser are multi-thread/process applications. Usually only a single tab or a plugin crashes unless core browser process is affected. Most users would accept the trade off between crashed browser and infected/corrupted system.
- sandGorgon 9y ago> From a security standpoint, when you find an invalid access, and you mitigate it, you've done a great job, and your hardening was successful and you're done. "Look ma, it's not a security issue any more", and you can basically ignore it as "just another bug" that is now in a class that is no longer your problem. So to you, the big win is when the access is _stopped_. That's the end of the story from a security standpoint - at least if you are one of those bad security people who don't care about anything else. But from a developer standpoint, things _really_ are not done. Not even close. From a developer standpoint, the bad access was just a symptom, and it needs to be reported, and debugged, and fixed, so that the bug actually gets corrected. As a developer, I do want the report. But if you killed the user program in the process, I'm actually _less_ likely to get the report, because the latent access was most likely in some really rare and nasty case, or we would have found it already. I dont think Linus has an invalid point there. Taken from his previous thread - https://www.spinics.net/lists/kernel/msg2540934.html https://www.spinics.net/lists/kernel/msg2540934.html > Don't bother with grsecurity. Their approach has always been "we don't care if we break anything, we'll just claim it's because we're extra secure". He is worried that grsecurity does not play nice with the kernel in a way of "let's make security hardening obsolete by fixing bugs in the kernel".
- jbangert 9y agoFixing all memory corruption bugs is infeasible without fundamentally changing the way Linux is developed. There is so much code (and it’s being added to, changed, etc.) written by humans that make mistakes. There will always be some bugs that are in between being discovered (by someone, maybe malicious, maybe not), and being fixed. How else do you prevent against vulnerabilities in that stage?
- banachtarski 9y agoLinus' response is that calling it an infeasible problem is a cop-out. The right way to go about it is to fix them all, incrementally if need be, and not break userland in the process.
- 9y ago
- mtgx 9y agoBecause Linus hates them? Make Brad Spengler the primary maintainer of the Linux kernel and we may actually get self-driving cars that don't kill us when they get hacked in 5 years.
- pgeorgi 9y ago> Make Brad Spengler the primary maintainer of the Linux kernel and we may actually get self-driving cars that don't kill us when they get hacked in 5 years. But only because every self-driving car project out there will avoid Linux like the plague.
- TimPC 9y agoInstead of self-driving cars maybe crashing from being hacked in some possible future we'll get kernel panics leading to crashes in all possible futures because we'll trigger car crashes on every false positive, because crashing in the face of the unknown is a seemingly acceptable solution to a security risk. Even if the software is running self-driving cars and crashing may mean crashing. In practice, false positives are way more common than exploits and in many user cases they'd rather have 1 computer exploit than 1000 or 10,000 crashes.
- torpcoms 9y agoYou would rather have a self driving car in an undefined state, rather than having it shut down? A random glitch could be just as bad as an exploit; if some chunk of memory gets overwritten and your car decides that the brick wall doesn't actually exist any more, I don't think whether it was an an exploit or not really matters. The occupants end up injured either way.
- pgeorgi 9y agoThe undefined state might be in the GPU driver handling the heads-up display, or maybe in the sound subsystem. No need to shut down the system at the kernel level for that. Report the issue to the userland, so that it can decide whether to initiate a safe halt at the sidewalk or emergency lane. After telling the kernel to shut down immediately you don't have that option any longer.
- phkahler 9y ago>> This is exactly what you want if you care about security, but it's not a trade-off everyone is happy with (including Linus). Let's rephrase that. This is exactly what you want if you care only about security, or care about security above everything else - including your system running at all. People run software for reasons, and they need it to keep running for those reasons. The security folks are not really qualified to evaluate the security risks against all the reasons for all the people running Linux.
- silly-silly 9y agoNo, they really are. Don't confuse doing it poorly with the ability to do it.
- nerdponx 9y agoWhy isn't Grsecurity publicly available anymore?
- Sir_Cmpwn 9y ago>If the large companies who use Linux really want to improve kernel security, they need to work with Grsecurity and not against them. It's beyond me how this isn't happening already. It's more that Grsecurity is working against everyone else. They want to pretend the GPL works in a way that it doesn't so that they can sell their patches. Then they make threats to people who say "that's not how the GPL works" and distribute their patches in accordance with how the GPL actually works. That's not how kernel development is done. I'd rather have an insecure kernel than their bullshit.
- eugeneionesco 9y agoYou're spreading FUD. I suggest you educate yourself on the reasons grsecurity patches are no longer public anymore.
- Sir_Cmpwn 9y agoYou're welcome to present an argument for your case.
- tptacek 9y agoIt's their work. We're not entitled to it.
- Sir_Cmpwn 9y agoActually, we are. That's how the GPL works.
- tptacek 9y agoNo, it's not. The GPL on the Linux kernel means that grsec can't distribute a new Linux kernel with their patches while withholding code. That's not what they're doing. If I write a Linux kernel patch on a consulting project, I am absolutely not required to publish it.
- 9y ago
- mcguire 9y ago"Grsecurity will rather terminate userland programs or, in some rare cases, panic the kernel if it finds itself in an undefined state. This is exactly what you want if you care about security, but it's not a trade-off everyone is happy with (including Linus)." If you really cared about security, you'd leave the box unplugged. "I remember many bugs that were uncovered by PAX_REFCOUNT and yes, occasionally panicked the kernel where a vanilla kernel would run just fine. They usually found and fixed those within hours." Speaking as someone who has done middling large scale production administration, that's not reassuring.