
HardenedLinux: The way to the Ark - hardenedlinux
https://hardenedlinux.github.io/announcement/2017/04/29/hardenedlinux-statement2.html
======
nagvx
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
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
Indeed, concreteness & specificity > generalness & neutrality in almost all
cases of writing and communication. It even makes for more catchy titles,
without being clickbaity.

------
ajdlinux
"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_annua...](https://www.coreinfrastructure.org/sites/cii/files/cii_annualreport_2016_fnl_digital.pdf)),
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
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
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
A little blurb at the top saying something like: "inspiration for this post
came from...", would probably be helpful.

------
Luker88
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
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_Projec...](https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project)

------
lclarkmichalek
> 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
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
I cant tell what you are responding to in the initial comment?

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

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

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

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

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

------
keypusher
> 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
Yes, but once you've given a copy to a subscriber, you can't stop them giving
that copy away to anyone else.

~~~
justincormack
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
How exactly do they enforce this? Do they have any measures to stop a
subscriber from posting their patches anonymously?

~~~
michaelt
Even if they don't have any precautions at the moment, if that happens they
could introduce them.

