
Passing the Baton - albuic
https://grsecurity.net/passing_the_baton.php
======
mrsteveman1
I suspect this will just shift focus to the Kernel Self Protection Project[1].

It may end up being the best thing that could have happened for kernel
security in the end.

[1]
[https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...](https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project)

~~~
walterbell
Could KSPP evolve to add missing features that are currently present in
grsecurity?

[https://grsecurity.net/compare.php](https://grsecurity.net/compare.php)

~~~
aseipp
If you're willing to wait a _long time_ , then yes, KSPP, in years, might
bring Linux kind-of on par with grsecurity today. If you mean in the short
term, well...

What will likely happen is people will base new features on the last public
4.9.x patches, the same way prior KSPP patches have been, such as PAX_REFCOUNT
or the read-only static variables, latent entropy, etc. (Frankly most of these
are uninteresting compared to the powerful things like RAP, UDEREF, size
overflow, etc, and the patches were in some cases neutered in other ways --
but whatever.)

However, grsecurity is more than that; if you watched the RSS feed,
substantial amounts of effort went into also monitoring upstream kernels and
carefully picking out security relevant commits and closing holes. The -stable
grsecurity trees often had (literally) hundreds of included bugfixes that
plugged things like minor infoleaks, 'benign' integer overflows, etc, when
compared to the stable mainline kernels.

(In fact, there were few better resources for getting a peek at security-
sensitive code "in the wild" being analyzed and fixed than looking at the
grsecurity RSS feed, IMO. Huge amounts of it was _very_ enlightening to
understand what kind of security sensitive issues you can find..)

When a substantial amount of your infrastructure is about anti-memory
corruption mitigations, taking care of stuff like infoleaks becomes more
important. It is both the combination of all of grsecurity's features --
making most attacks substantially more difficult, or simply outright
impossible in a lot of cases -- plus this kind of detailed attention -- not
just stopping whole techniques, but also mitigating _future_ possible attacks
-- that put it very far ahead of the competition. It is not just a patch set,
it is also very much a mind set, and a development model, behind the system.

In short, I don't agree this is the best thing that could happen for Linux
Security or the KSPP. It's one of the worst, in fact. I think it means the
KSPP will fall even further behind grsecurity as it will now develop all of
its new protections privately (such as the whispered KERNSEAL), and they will
be left to their own devices to develop new protections. (The current
grsecurity authors have over a decade of experience in advanced anti-
corruption techniques and kernel hardening, you're already starting the race
late.) And even if they _do_ rip the code out of the old kernels, and they
_do_ manage to keep it in tact without neutering or removing parts, it's not
clear to me the kernels will still have the level of attention or mindset
previously seen by the grsecurity team, which means it will overall still be
worse off.

I knew this was coming after the -stable trees were pulled. It sucks.

~~~
derefr
> substantial amounts of effort went into also monitoring upstream kernels and
> carefully picking out security relevant commits and closing holes

This would better be a project done by these same people, _in_ the upstream,
to ensure that the -stable branches of regular kernel packages receive
security updates, no?

~~~
aseipp
Brad has already answered this before.[1] In short: they have no interest in
cooperating with an upstream that feel -- in many ways -- does not appreciate
their work[2], and their view of their work is that it is a _complete system_
and greater than the sum of individual parts, which upstreaming can't solve on
its own.

Also, just picking out hundreds of bug fixes isn't _really_ improving kernel
security, in reality. It feels good, but it solves very little. It's playing
cat-and-mouse, whack-a-mole. You churn 1.5 million lines of code every 3
months, every major release of Linux, add tons of new code, and play the game
again. This approach is simply not sustainable in the long run. You also have
to have actual mitigation and defense techniques too -- and not just one of
them. You need a lot of them, working together.

In short, it's not just about a set of patches, or just fixing some
infoleaks.. The entire _development process_ needs to take part in this.

[1] [https://unix.stackexchange.com/questions/59020/why-are-
the-g...](https://unix.stackexchange.com/questions/59020/why-are-the-
grsecurity-patches-not-included-in-the-vanilla-kernel)

[2] While I cannot find a link on me, I actually 'fondly' remember a recent
memory somewhere from LKML, where someone (an ARM maintainer, I believe)
actively lashed out at Kees Cook for "bothering" to do this work and
attempting to upstream some of their work such as PAX_REFCOUNT. The reasoning?
Because it's "bullshit" to worry about losers who do not upstream, and making
their lives "easier" is a load of crap they shouldn't bother with, and it only
benefits people "who do not contribute back". At one point they even started
ranting about how people like Samsung similarly just 'take' and do not give
back. It took _several_ emails to explain, patiently, that in this scenario,
it is not about making anyone's life easier, nor benefitting shitty people
like Samsung -- it is about protecting users. And it's about having
mitigations that will stop exploits _today_ that don't get discovered until 5
years from now when millions of people are vulnerable with exposed devices.
This isn't a simple disagreement about how a patch should be implemented -- it
is a complete _misunderstanding_ of defense in depth, and true mitigation.

~~~
derefr
But the backporting-security-patches thing is _already done_ by every
distro—just, not as well as grsec+pax do it. Said distro maintainers just need
help to get their -stable kernels up to grsec/pax's _standard_ —at which point
the grsec/pax patchsets could be based directly _on top of_ each distro's
-stable kernel package, rather than having to do _all_ the work of backporting
again themselves.

Which would, of course, free up resources on the grsec/pax side to go toward
protecting users; and, moreover, would also _partially_ protect those users
who just rely on their distro's -stable kernel, more than they're being
protected today.

Perfect is the enemy of good; ideal security is the enemy of _less
vulnerable_.

------
qznc
Also read the corresponding FAQ:
[https://grsecurity.net/passing_the_baton_faq.php](https://grsecurity.net/passing_the_baton_faq.php)

------
chamakits
How does this work at a licensing level?

GRSecurity are patches to the Linux kernel right? Can you distribute patches
for a GPL licensed software without the patches themselves being GPL?

~~~
gbuk2013
Of course you can.

[https://01.org/linuxgraphics/gfx-docs/drm/admin-
guide/tainte...](https://01.org/linuxgraphics/gfx-docs/drm/admin-
guide/tainted-kernels.html)

Edit:

\---

Good point about the distinction between adding modules modifying existing
source. It is an interesting question, actually and I haven't been able to
find an authoritative answer on the subject.

A patch is a description of changes that would be made to a work, if they were
made. Does it trigger the licence before it is applied to the source tree? On
the other hand to generate a patch you would require the original source (even
if you write it by hand you would still have to look at the source to
determine line numbers). An you will probably have some bits of the source in
your diff, but they are not being used for anything other than position
information.

~~~
mrsteveman1
That's not the same thing at all.

The 'P' taint flag exists because upstream kernel maintainers aren't
interested in dealing with bug reports where the bug may have been caused by
proprietary code loaded by end users, which often can't be examined or copied
even for the purpose of discussing the bug. Total waste of time, so the flag
makes those cases obvious to anyone reading the bug report. The user can be
told upfront to remove the proprietary code and try to reproduce the bug
again.

 _End users_ can combine proprietary code with GPL code if they want to,
because end users aren't bound by the GPL unless and until they _distribute_
something covered by it. You don't even have to _accept_ the terms of the GPL
just to run the program[1].

A company distributing a proprietary module for the kernel may or may not be
violating the GPL, depending on what it does and who you ask.

In contrast to the module stuff, GRSecurity is a set of patches to very low
level parts of the Linux kernel itself. It could never be licensed in a way
that prevented the patch set or the resulting patched kernel source/binaries
from being covered and distributed under the GPLv2. If that were the case, the
kernel would effectively not be covered by the GPL at all.

[1]
[https://www.gnu.org/licenses/gpl-2.0.en.html#section5](https://www.gnu.org/licenses/gpl-2.0.en.html#section5)

~~~
mnarayan01
> It could never be licensed in a way that prevented the patch set or the
> resulting patched kernel source/binaries from being covered and distributed
> under the GPLv2. If that were the case, the kernel would effectively not be
> covered by the GPL at all.

Is this true? I would think that as long as your "new" code is sufficiently
distinct from the stuff you're replacing, you'd be fine distributing a non-GPL
patch (at least if it's e.g. purely positional to elide context related
issues). The result of _applying_ the patch would not be distributable, but
I'd think the patch itself would be fine.

~~~
peterwwillis
Distribute changes, it's all GPL. Don't distribute changes, it's whatever you
want it to be. This does not change depending on how "distinct" your change
is.

~~~
cyphar
I'd argue that the code is always GPL, it's just that if you don't distribute
it then the GPL doesn't have any restrictions.

------
amluto
This outcome makes me kind of sad. I bet there would be people willing to fund
development of grsecurity and PaX in the open (i.e. with broken out patches,
etc.), and there could plausibly be more money in that than in selling
subscriptions.

------
zkms
the FAQ mentions "KERNSEAL, STRUCTGUARD" \-- what are these? I tried searching
on google but didn't find anything about either.

------
admax88q
I love how grsecurity is always quick to point out how generous they have been
by providing the patches for free.

> We have been providing grsecurity freely for 16 years.

Meanwhile the kernel upon which their work is built has been provided for free
for much longer, and continues to be.

~~~
PaXTeam
you conveniently forgot to mention the fundamental difference: the upstream
kernel isn't _developed_ for free whereas our code has always been. changes
the equation quite a bit, doesn't it?

~~~
cryptarch
What do you mean, the Linux kernel isn't developed for free? Many contributors
aren't paid.

And do you have proof that PaXTeam is not paid, if you are indeed PaXTeam?

~~~
PaXTeam
> What do you mean, the Linux kernel isn't developed for free? Many
> contributors aren't paid.

you're wrong, see item 6 in
[https://opensource.com/article/16/12/yearbook-9-lessons-25-y...](https://opensource.com/article/16/12/yearbook-9-lessons-25-years-
linux-kernel-development) though you might want to demand that Greg prove his
identity first ;).

> And do you have proof that PaXTeam is not paid, if you are indeed PaXTeam?

sure, come visit me in hungary and i'll take you to the local tax authorities
and grant you access to my files. of course you'll have to prove your own
identity first ;).

~~~
cryptarch
You mean that some developers are paid to implement things by companies? Fair
enough, though I'd still argue it's not developed commercially because no one
pays to get access to the result (they only pay to influence the result).

>> sure, come visit me in hungary

That'd be amusing, maybe sometime this summer? I'm kinda busy right now
setting up my business :')

Let me know when you're around the Benelux, we could do the key-siging song-
and-dance over a coffee or beer.

