5 ms·

HardenedLinux: The way to the Ark

106 points by hardenedlinux 9y ago

d33 9y ago
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?
- Foxboron 9y ago
  Arch Linux has provided the kernel with grsecurity patches inn the main repos for a long time.
  - dfc 9y ago
    The question was about the main kernel package in a distribution. Lots of distributions had optional packages with grsec support.
  - qznc 9y ago
    "The PaX and grsecurity patches are no longer going to be public, so official support in Arch Linux has ended" https://lists.archlinux.org/pipermail/arch-general/2017-April/043604.html https://lists.archlinux.org/pipermail/arch-general/2017-Apri...
    - Foxboron 9y ago
      Yes. I wrote "has".
      - joh6nn 9y ago
        "has" is present tense. I think you meant "had"?
    - gribbly 9y ago
      The 'hardened' kernel he mentioned has recently (~40 hours) appeared in the Arch repos: https://www.archlinux.org/packages/community/x86_64/linux-hardened/ https://www.archlinux.org/packages/community/x86_64/linux-ha... Not a replacement but at least an alternative.
- justincormack 9y ago
  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.
- viraptor 9y ago
  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).
  - staticassertion 9y ago
    > 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.
    - viraptor 9y ago
      > Most will not break userland 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.
- snaky 9y ago
  > The Gentoo Hardened project maintains security-enhancement features for Gentoo, including but not limited to grsecurity https://wiki.gentoo.org/wiki/Hardened/Grsecurity2_Quickstart#Gentoo_Hardened_integration https://wiki.gentoo.org/wiki/Hardened/Grsecurity2_Quickstart...
Luker88 9y ago
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?
- Luker88 9y ago
  It Seems that actually some stuff has been ported and other is in progress. The gentoo guys keep tracing of it nicely: https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Projec...
lclarkmichalek 9y ago
> 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. I really enjoyed this talk about KSPP's agenda: https://www.youtube.com/watch?v=aMkCKeZ8xZw https://www.youtube.com/watch?v=aMkCKeZ8xZw
- hardenedlinux 9y ago
  as citypw posted it on: https://lwn.net/Articles/703000/ 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/ 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.
  - dfc 9y ago
    I cant tell what you are responding to in the initial comment?
    - cryptarch 9y ago
      It seems to back up this quote: >> 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.
ajdlinux 9y ago
"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" 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_annualreport_2016_fnl_digital.pdf 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]
dfc 9y ago
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.
- tgragnato 9y ago
  I had to read https://lwn.net/Articles/721122/ https://lwn.net/Articles/721122/ to understand their point. 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
  - bluejekyll 9y ago
    A little blurb at the top saying something like: "inspiration for this post came from...", would probably be helpful.
- tyingq 9y ago
  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.
  - ReligiousFlames 9y ago
    I couldn't make heads-or-tails of it, and stopped reading.
nagvx 9y ago
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?
- fenomas 9y ago
  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.
  - SkyMarshal 9y ago
    Indeed, concreteness & specificity > generalness & neutrality in almost all cases of writing and communication. It even makes for more catchy titles, without being clickbaity.
keypusher 9y ago
> 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?
- CJefferson 9y ago
  Yes, but once you've given a copy to a subscriber, you can't stop them giving that copy away to anyone else.
  - justincormack 9y ago
    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.
    - ajdlinux 9y ago
      How exactly do they enforce this? Do they have any measures to stop a subscriber from posting their patches anonymously?
      - michaelt 9y ago
        Even if they don't have any precautions at the moment, if that happens they could introduce them.
- AlphaWeaver 9y ago
  If the agreement does not prohibit redistribution of the source code once you have it, it can still be considered GPL.
- kebolio 9y ago
makomk 9y ago
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 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.
unlmtd 9y ago
GPL at fault. Use public domain to avoid this drama. There is no thought which you can call your own.
dankohn1 9y ago
Informative response from Kees Cook of the Kernel Self-Protection Project (KSPP): http://www.openwall.com/lists/kernel-hardening/2017/05/02/4 http://www.openwall.com/lists/kernel-hardening/2017/05/02/4

106 points by hardenedlinux 9y ago

d33 9y ago

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?

Foxboron 9y ago
Arch Linux has provided the kernel with grsecurity patches inn the main repos for a long time.
- dfc 9y ago
  The question was about the main kernel package in a distribution. Lots of distributions had optional packages with grsec support.
- qznc 9y ago
  "The PaX and grsecurity patches are no longer going to be public, so official support in Arch Linux has ended" https://lists.archlinux.org/pipermail/arch-general/2017-April/043604.html https://lists.archlinux.org/pipermail/arch-general/2017-Apri...
  - Foxboron 9y ago
    Yes. I wrote "has".
    - joh6nn 9y ago
      "has" is present tense. I think you meant "had"?
  - gribbly 9y ago
    The 'hardened' kernel he mentioned has recently (~40 hours) appeared in the Arch repos: https://www.archlinux.org/packages/community/x86_64/linux-hardened/ https://www.archlinux.org/packages/community/x86_64/linux-ha... Not a replacement but at least an alternative.
justincormack 9y ago
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.
viraptor 9y ago
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).
- staticassertion 9y ago
  > 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.
  - viraptor 9y ago
    > Most will not break userland 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.
snaky 9y ago
> The Gentoo Hardened project maintains security-enhancement features for Gentoo, including but not limited to grsecurity https://wiki.gentoo.org/wiki/Hardened/Grsecurity2_Quickstart#Gentoo_Hardened_integration https://wiki.gentoo.org/wiki/Hardened/Grsecurity2_Quickstart...

Luker88 9y ago

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?

Luker88 9y ago
It Seems that actually some stuff has been ported and other is in progress. The gentoo guys keep tracing of it nicely: https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Projec...

lclarkmichalek 9y ago

> 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. I really enjoyed this talk about KSPP's agenda: https://www.youtube.com/watch?v=aMkCKeZ8xZw https://www.youtube.com/watch?v=aMkCKeZ8xZw

hardenedlinux 9y ago
as citypw posted it on: https://lwn.net/Articles/703000/ 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/ 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.
- dfc 9y ago
  I cant tell what you are responding to in the initial comment?
  - cryptarch 9y ago
    It seems to back up this quote: >> 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.

ajdlinux 9y ago

"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" 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_annualreport_2016_fnl_digital.pdf 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]

dfc 9y ago

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.

tgragnato 9y ago
I had to read https://lwn.net/Articles/721122/ https://lwn.net/Articles/721122/ to understand their point. 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
- bluejekyll 9y ago
  A little blurb at the top saying something like: "inspiration for this post came from...", would probably be helpful.
tyingq 9y ago
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.
- ReligiousFlames 9y ago
  I couldn't make heads-or-tails of it, and stopped reading.

nagvx 9y ago

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?

fenomas 9y ago
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.
- SkyMarshal 9y ago
  Indeed, concreteness & specificity > generalness & neutrality in almost all cases of writing and communication. It even makes for more catchy titles, without being clickbaity.

keypusher 9y ago

> 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?

CJefferson 9y ago
Yes, but once you've given a copy to a subscriber, you can't stop them giving that copy away to anyone else.
- justincormack 9y ago
  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.
  - ajdlinux 9y ago
    How exactly do they enforce this? Do they have any measures to stop a subscriber from posting their patches anonymously?
    - michaelt 9y ago
      Even if they don't have any precautions at the moment, if that happens they could introduce them.
AlphaWeaver 9y ago
If the agreement does not prohibit redistribution of the source code once you have it, it can still be considered GPL.
kebolio 9y ago

makomk 9y ago

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

unlmtd 9y ago

GPL at fault. Use public domain to avoid this drama. There is no thought which you can call your own.

dankohn1 9y ago

Informative response from Kees Cook of the Kernel Self-Protection Project (KSPP): http://www.openwall.com/lists/kernel-hardening/2017/05/02/4 http://www.openwall.com/lists/kernel-hardening/2017/05/02/4