This is terribly unfortunate. By the way, could someone comment on why major distributions didn't use grsecurity code in their main kernel packages (or at least provide hardened-) ones? Maintenance cost or something else?
The major distros gave up using significant amounts of non upstream code a decade or so ago, as it was extremely difficult to support. The only people who ship the grsec kernels ship them pretty much unmodified.
You can't really ship all of the grsec, because some compile time settings break userspace apps. Other options disable things you want on laptops, like power management registers. Basically your need to opt-in to grsec and you need to know what to configure afterwards. Or enable only selected few features and not get the whole protection.
On top of that, you can't use the latest kernel version until grsec is ported to it. And probably more reasons I don't know about yet. Basically, it's not one-size-fits-all solution - Ubuntu would create more problems than solutions if they just dumped it on users by default (or at least without a proper migration path with lots of deprecation time).
>
You can't really ship all of the grsec, because some compile time settings break userspace apps. Other options disable things you want on laptops, like power management registers. Basically your need to opt-in to grsec and you need to know what to configure afterwards. Or enable only selected few features and not get the whole protection.
The vast majority of features are 'set and forget'. Most will not break userland, or have extremely low FP rates. I can think of only one or two that have a high FP rate (integer overflow plugin) that would not be enabled by default. After all, these patches tend to make it into upstream under another name in ~10 years or so.
> On top of that, you can't use the latest kernel version until grsec is ported to it.
Not really a problem unless your distro updates to the latest version the night it's released, which most will not. Grsecurity's dev patch tends to be far, far ahead of whatever Ubuntu is using.
I ran it on an Ubuntu system with virtually all features enabled with little problem.
That's exactly what I meant. It usually works the same. Apart from when it doesn't. For example arch's linux-grsec kernel requires pax changes for common KDE apps, and every separate python virtualenv. Restricted runtime CPU registers stop powertop. Something (can't remember details now) affected sysdig.
It's not critical. I used to run grsec kernel all the time on a laptop. But I can't imagine someone dropping, for example paxd support into a popular distro and expect people to deal with apps suddenly not starting.
We've been using PaX/Grsecurity on Debian( as server) and Linux Mint( as Desktop) for a while. It's working perfect fine until now. You can also tweak the reproducible builds as well:
Losing public grsec is really bad for the community.
But I see too may posts talking about "the truth" and hard political stances.
Grsec has done a fantastic job since the beginning. Some of it has been ported to mainline. Hopefully this will speed up the port to mainline.
But why? I remember some discussions where Linus did not want to accept the whole patch as-is, without breaking it into smaller standalone pieces. I remember that some protection might have caused userspace changes.
Sure, if it breaks with grsec, then there was a big problem at the beginning, but you can't just ignore everyone else either.
Were there are some problems with the GCC plugins and licensing? Was it something about not being able to advance to newer GCC because it is GPL3, and somehow the plugins would have needed to propagate the license to the resulting kernel binary? Can anyone elaborate?
Can anyone point out to some more unbiased tracking of what happened here? Some LKML link?
> But… till now they’ve hardly accomplished anything compared to what PaX/Grsecurity did, e.g. they ported some mitigations while introducing more (exploitable?) bugs or incomplete implementations
That doesn't seem particularly charitable. Regardless of what you think of the Linux Foundation's marketing arm, the KSPP is not a bad thing. They seem to have a very different priority to PaX/Grsecurity, with an emphasis on things that have a clear technical/political/etc path to being enabled by default.
We don't have such leap of faith in KSPP due to there are several exploitable bugs( CVE-2017-0358, CVE-2016-1583, CVE-2016-0728, CVE-2017-6074, CVE-2017-7184, etc), which can be turned to "massive" exploitations in past couple of months. And it's just the tip of the iceberg in past 16 years:
There are tons of features from PaX/Grsecurity, e.g: PAGEEXEC/SEGEXEC/ASLR/KERNEXEC/UDEREF/MPROTECT/RAP/etc. None of them are created by KSPP even though some vendors integrated some of features( weakened usually) into hardware in recent years.
"Core Infrastructure Initiative has been funded by 19 big corps( $1.9 mil per year) and organized by Linux foundation. KSPP was funded by CII in the begining"
$80,000 in funding isn't exactly going to pay for all of grsecurity to be successfully upstreamed overnight. Emese and David have been doing fantastic work, and I'm really, really glad that CII has provided funding for them, but CII is only providing project-based funding for specific work items, not a continuous stream of money to fund the KSPP. Seems a bit unfair to criticise the KSPP on these grounds...
[disclosure: I've sent the occasional minor patch to kernel-hardening in my capacity as an employee of IBM who sponsor the CII, opinions my own, I don't know anything at all about our CII funding]
I will be honest, I have read this post three times times now and I still don't know what the central thesis is. Initially when I read the post the HN submission was titled something along the lines of "Why the public grsec patches stopped". It's pretty clear that CII is the who, but I have no idea what the author thinks CII did or why it resulted in the end of the public availability of the beta grsec patches.
Makes you wonder if that's the core issue here. If you can't communicate well, you would likely end up with issues convincing the kernel devs to take your patches, and a harder time attracting contributors.
Why was the title changed? The old title was not great, but at least informed us that a) the article was about PaX/Grsec, and b) was trying to present another side to the story.
HN has replaced this with the title of an obscure Linux project, and an awkward and unhelpful metaphor - capitalisation kept, of course, so readers can wrongly assume that "Ark" is the name some piece of software. Yes, it's original, pure and untouched. No, it's not helpful, it's just worse in every way.
I understand that editorialising titles is a bad thing. But if a human is taking the time to make a judgement call on what is or is not editorialised, why not take a few extra minutes to create a more neutral title?
I really agree. Every time I notice that a title has been changed lately, the edited version is always blander, vaguer, and gives less of an idea what the article is about. There's another example on the front page even now ("esoteric programming paradigms").
Whoever edits titles seems to value brevity and neutrality more highly than saying what's in the article, lately.
Indeed, concreteness & specificity > generalness & neutrality in almost all cases of writing and communication. It even makes for more catchy titles, without being clickbaity.
> Closing the public access doesn’t make PaX/Grsecurity a non-free/libre software. Those who purchase subscriptions can access the source code. We don’t see GPL violated in any way here.
I'm not an expert in software licenses, but this seems wrong. Can you really have "free" GPL software that requires a subscription fee?
They will refuse to sell you it again if you do, and given that for security patches you need updates this is fairly effective. They will also refuse to sell to anyone who distributes their kernels, and thus would be obliged to redistribute source, you can only buy it for on premise use. So yes, it falls within the letter of the GPL, and it could in theory be distributed, but it is not in practise.
You can sell GPL software under all the terms of the GPL, but the users can redistribute it under freedom 0, 2 and 3. You can mitigate this by being a single source of development and offering support.
Even before this announcement, important parts of the PaX/grsec gcc plugins were apparently not part of the public release, rendering the claimed protections ineffective: https://twitter.com/paxteam/status/858446189624164352 I'm not sure if this was ever publicly announced, or if it was only became public because security testers discovered the bypass and the PaX team responded by saying this wasn't an issue in the private release which they couldn't have access to for testing.
38 comments
[ 2.5 ms ] story [ 90.9 ms ] threadhttps://lists.archlinux.org/pipermail/arch-general/2017-Apri...
https://www.archlinux.org/packages/community/x86_64/linux-ha...
Not a replacement but at least an alternative.
On top of that, you can't use the latest kernel version until grsec is ported to it. And probably more reasons I don't know about yet. Basically, it's not one-size-fits-all solution - Ubuntu would create more problems than solutions if they just dumped it on users by default (or at least without a proper migration path with lots of deprecation time).
The vast majority of features are 'set and forget'. Most will not break userland, or have extremely low FP rates. I can think of only one or two that have a high FP rate (integer overflow plugin) that would not be enabled by default. After all, these patches tend to make it into upstream under another name in ~10 years or so.
> On top of that, you can't use the latest kernel version until grsec is ported to it.
Not really a problem unless your distro updates to the latest version the night it's released, which most will not. Grsecurity's dev patch tends to be far, far ahead of whatever Ubuntu is using.
I ran it on an Ubuntu system with virtually all features enabled with little problem.
That's exactly what I meant. It usually works the same. Apart from when it doesn't. For example arch's linux-grsec kernel requires pax changes for common KDE apps, and every separate python virtualenv. Restricted runtime CPU registers stop powertop. Something (can't remember details now) affected sysdig.
It's not critical. I used to run grsec kernel all the time on a laptop. But I can't imagine someone dropping, for example paxd support into a popular distro and expect people to deal with apps suddenly not starting.
https://github.com/hardenedlinux/grsecurity-reproducible-bui...
As exmaple of Linux Mint: https://hardenedlinux.github.io/system-security/2016/01/10/h...
https://wiki.gentoo.org/wiki/Hardened/Grsecurity2_Quickstart...
But I see too may posts talking about "the truth" and hard political stances.
Grsec has done a fantastic job since the beginning. Some of it has been ported to mainline. Hopefully this will speed up the port to mainline.
But why? I remember some discussions where Linus did not want to accept the whole patch as-is, without breaking it into smaller standalone pieces. I remember that some protection might have caused userspace changes. Sure, if it breaks with grsec, then there was a big problem at the beginning, but you can't just ignore everyone else either. Were there are some problems with the GCC plugins and licensing? Was it something about not being able to advance to newer GCC because it is GPL3, and somehow the plugins would have needed to propagate the license to the resulting kernel binary? Can anyone elaborate?
Can anyone point out to some more unbiased tracking of what happened here? Some LKML link?
https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Projec...
That doesn't seem particularly charitable. Regardless of what you think of the Linux Foundation's marketing arm, the KSPP is not a bad thing. They seem to have a very different priority to PaX/Grsecurity, with an emphasis on things that have a clear technical/political/etc path to being enabled by default.
I really enjoyed this talk about KSPP's agenda: https://www.youtube.com/watch?v=aMkCKeZ8xZw
https://lwn.net/Articles/703000/
We don't have such leap of faith in KSPP due to there are several exploitable bugs( CVE-2017-0358, CVE-2016-1583, CVE-2016-0728, CVE-2017-6074, CVE-2017-7184, etc), which can be turned to "massive" exploitations in past couple of months. And it's just the tip of the iceberg in past 16 years:
https://lwn.net/Articles/721122/
There are tons of features from PaX/Grsecurity, e.g: PAGEEXEC/SEGEXEC/ASLR/KERNEXEC/UDEREF/MPROTECT/RAP/etc. None of them are created by KSPP even though some vendors integrated some of features( weakened usually) into hardware in recent years.
>> they ported some mitigations while introducing more (exploitable?) bugs or incomplete implementations
I also disagree with GP that there isn't much of a point in using KSPP if it makes your system less secure and is not maintained diligently.
That $1.9 million is for the whole CII.
According to the CII annual report for 2016 (https://www.coreinfrastructure.org/sites/cii/files/cii_annua...), CII provided $80,000 in funding to support Emese Revfy and David Windsor on GCC plugins.
$80,000 in funding isn't exactly going to pay for all of grsecurity to be successfully upstreamed overnight. Emese and David have been doing fantastic work, and I'm really, really glad that CII has provided funding for them, but CII is only providing project-based funding for specific work items, not a continuous stream of money to fund the KSPP. Seems a bit unfair to criticise the KSPP on these grounds...
[disclosure: I've sent the occasional minor patch to kernel-hardening in my capacity as an employee of IBM who sponsor the CII, opinions my own, I don't know anything at all about our CII funding]
After that, I read the whole post as a
- the kernel developers are refusing to merge our patches for technically wrong reasons
- the only reason for KSPP to exist is to upstream "incomplete/bogus/weakened" implementations of our solutions
- no one is contributing
HN has replaced this with the title of an obscure Linux project, and an awkward and unhelpful metaphor - capitalisation kept, of course, so readers can wrongly assume that "Ark" is the name some piece of software. Yes, it's original, pure and untouched. No, it's not helpful, it's just worse in every way.
I understand that editorialising titles is a bad thing. But if a human is taking the time to make a judgement call on what is or is not editorialised, why not take a few extra minutes to create a more neutral title?
Whoever edits titles seems to value brevity and neutrality more highly than saying what's in the article, lately.
I'm not an expert in software licenses, but this seems wrong. Can you really have "free" GPL software that requires a subscription fee?
http://www.openwall.com/lists/kernel-hardening/2017/05/02/4