Mailing List Archive

Technical repercussions of grsecurity removal
Hi all,

There is a nice debate ongoing on the mailinglist [1] on the topic of
grsecurity's recent decision to no longer provide the test patches to the
public. I'd like to keep the debate on the rationale of it in that
discussion, but focus here on what we, from Gentoo Hardened, now need to do
or which direction we're going to move forward with.

[1]
https://archives.gentoo.org/gentoo-hardened/message/a06145056b167f52c079bffd9c9a51ac

The obvious step is indeed to stop further *current* development on
hardened-sources. I don't know how many additional patchsets are being
implemented in it (blueness? Zorry?) so I don't know if it means that
hardened-sources in total is done with or not.

From the online discussions I also hear that we shouldn't be referring to
grsecurity anymore (even when it was still the test patches). This means
that we need to update our wiki articles, as well as include a note that the
document is only valid until a certain time (I don't want to remove them,
for those users that still have older versions running and want to find the
documentation on it).

Now, I mentioned *current* development. Are there other improvements that we
can look at which make sense to put into hardened-sources, and are there
volunteers to help out with it?

Wkr,
Sven Vermeulen
Re: Technical repercussions of grsecurity removal [ In reply to ]
On Mon, May 01, 2017 at 09:38:43AM +0000, Sven Vermeulen wrote:
> From the online discussions I also hear that we shouldn't be referring to
> grsecurity anymore (even when it was still the test patches). This means
> that we need to update our wiki articles, as well as include a note that the
> document is only valid until a certain time (I don't want to remove them,
> for those users that still have older versions running and want to find the
> documentation on it).

This seems to be incorrect - it is only if we would continue building on top
of the latest patch set release that we need to remove the grsecurity name.

https://grsecurity.net/passing_the_baton_faq.php

So all we would need to do on the wiki pages is to mark them as deprecated
in a timely fashion.

Wkr,
Sven Vermeulen
Re: Technical repercussions of grsecurity removal [ In reply to ]
2017-05-01 11:38 GMT+02:00 Sven Vermeulen <swift@gentoo.org>:
> Hi all,
>
> There is a nice debate ongoing on the mailinglist [1] on the topic of
> grsecurity's recent decision to no longer provide the test patches to the
> public. I'd like to keep the debate on the rationale of it in that
> discussion, but focus here on what we, from Gentoo Hardened, now need to do
> or which direction we're going to move forward with.
>
> [1]
> https://archives.gentoo.org/gentoo-hardened/message/a06145056b167f52c079bffd9c9a51ac
>
> The obvious step is indeed to stop further *current* development on
> hardened-sources. I don't know how many additional patchsets are being
> implemented in it (blueness? Zorry?) so I don't know if it means that
> hardened-sources in total is done with or not.

Hi,

I have already written my opinion:

https://archives.gentoo.org/gentoo-hardened/message/97ccd6d5eb7f94c3cce2ac48ed41a7bb

https://archives.gentoo.org/gentoo-hardened/message/139ab72c413b2b83e08c948b061882bf


Summing up:

* PaX is the most important part of Gentoo Hardened project
(Grsecurity, SELinux, RSBAC)

* We can't use the 'grsecurity' name, which means that fork of
grsecurity == rewriting everything with 'grsecurity' (or 'grsec')
name... (~225k LOC grsec+PaX)

* PaX (~176k LOC) is available as a separate patch (1), so we can use
it without the risk of 'grsecurity' trademark

My opinion is: we should continue to use PaX patch and keep the Gentoo
Hardened project alive.

(1) https://www.grsecurity.net/~paxguy1/

Daniel
Re: Technical repercussions of grsecurity removal [ In reply to ]
On Mon, 1 May 2017 09:38:43 +0000 Sven Vermeulen wrote:
> Hi all,
>
> There is a nice debate ongoing on the mailinglist [1] on the topic of
> grsecurity's recent decision to no longer provide the test patches to the
> public. I'd like to keep the debate on the rationale of it in that
> discussion, but focus here on what we, from Gentoo Hardened, now need to do
> or which direction we're going to move forward with.
>
> [1]
> https://archives.gentoo.org/gentoo-hardened/message/a06145056b167f52c079bffd9c9a51ac
>
> The obvious step is indeed to stop further *current* development on
> hardened-sources.

Why not support hardened-sources while corresponding vanilla
kernels are still supported? E.g. 4.9 is a longterm branch, so we
should be able to keep hardened-sources-4.9* up-to-date with
vanilla bugfixes. This will give a nice transition period for
hardened users.

Best regards,
Andrew Savchenko
Re: Technical repercussions of grsecurity removal [ In reply to ]
Hi,

On Mon, 1 May 2017 12:24:14 +0200 Daniel Cegie?ka wrote:
[...]
> Summing up:
>
> * PaX is the most important part of Gentoo Hardened project
> (Grsecurity, SELinux, RSBAC)
>
> * We can't use the 'grsecurity' name, which means that fork of
> grsecurity == rewriting everything with 'grsecurity' (or 'grsec')
> name... (~225k LOC grsec+PaX)
>
> * PaX (~176k LOC) is available as a separate patch (1), so we can use
> it without the risk of 'grsecurity' trademark
>
> My opinion is: we should continue to use PaX patch and keep the Gentoo
> Hardened project alive.
>
> (1) https://www.grsecurity.net/~paxguy1/

Are you sure PaX patches will be updated? Because PaXTeam claims
they will not be published [1]:

"As this is a joint decision, there will be no public PaX patches
for future kernels. This is effective April 26th 2017."

Or do you suggest to support PaX with our own resources?

[1] https://grsecurity.net/passing_the_baton_faq.php


Best regards,
Andrew Savchenko
Re: Technical repercussions of grsecurity removal [ In reply to ]
2017-05-01 13:00 GMT+02:00 Andrew Savchenko <bircoph@gentoo.org>:
> Hi,
>
> On Mon, 1 May 2017 12:24:14 +0200 Daniel Cegie?ka wrote:

> Are you sure PaX patches will be updated? Because PaXTeam claims
> they will not be published [1]:

(...)

> Or do you suggest to support PaX with our own resources?

https://archives.gentoo.org/gentoo-hardened/message/97ccd6d5eb7f94c3cce2ac48ed41a7bb
Re: Technical repercussions of grsecurity removal [ In reply to ]
On Mon, May 01, 2017 at 01:28:54PM +0300, Andrew Savchenko wrote:
> > The obvious step is indeed to stop further *current* development on
> > hardened-sources.
>
> Why not support hardened-sources while corresponding vanilla
> kernels are still supported? E.g. 4.9 is a longterm branch, so we
> should be able to keep hardened-sources-4.9* up-to-date with
> vanilla bugfixes. This will give a nice transition period for
> hardened users.

Transition to what exactly?

There is one suggestion that mentions we would join forces with other
projects "out there" to keep supporting the latest PaX patches. But this
will require knowledgeable resources with enough time to do the necessary
support on it.

In my humble opinion, this is an effort which is not to be underestimated.
Maintaining the upstream-provided patches within Gentoo is already an
endeavour, and now we're talking about even taking on the patch content
itself as well.

If we have enough volunteers to do so, then let's do it. At least we can
then have something for users to look forward to. If not, then the current
long-term branch is also the latest, and the "transition period" is to allow
users to move to a perhaps lesser kernel-hardened environment.

Wkr,
Sven Vermeulen
Re: Technical repercussions of grsecurity removal [ In reply to ]
There is Subgraph that is going to keep maintaining 4.9.X LTS branch
with grsec & there is minipli[1] that is going to forward 4.9.X LTS
branch with grsec.

Would be great to join forces to keep 4.9.X LTS alive while porting
features upstream.

1.
https://github.com/minipli/linux-unofficial_grsec/tree/linux-4.9.x-unofficial_grsec


On 05/01/2017 03:58 PM, Sven Vermeulen wrote:

> On Mon, May 01, 2017 at 01:28:54PM +0300, Andrew Savchenko wrote:
>>> The obvious step is indeed to stop further *current* development on
>>> hardened-sources.
>> Why not support hardened-sources while corresponding vanilla
>> kernels are still supported? E.g. 4.9 is a longterm branch, so we
>> should be able to keep hardened-sources-4.9* up-to-date with
>> vanilla bugfixes. This will give a nice transition period for
>> hardened users.
> Transition to what exactly?
>
> There is one suggestion that mentions we would join forces with other
> projects "out there" to keep supporting the latest PaX patches. But this
> will require knowledgeable resources with enough time to do the necessary
> support on it.
>
> In my humble opinion, this is an effort which is not to be underestimated.
> Maintaining the upstream-provided patches within Gentoo is already an
> endeavour, and now we're talking about even taking on the patch content
> itself as well.
>
> If we have enough volunteers to do so, then let's do it. At least we can
> then have something for users to look forward to. If not, then the current
> long-term branch is also the latest, and the "transition period" is to allow
> users to move to a perhaps lesser kernel-hardened environment.
>
> Wkr,
> Sven Vermeulen
>
Re: Technical repercussions of grsecurity removal [ In reply to ]
2017-05-01 16:20 GMT+02:00 SK <yandereson@riseup.net>:
> There is Subgraph that is going to keep maintaining 4.9.X LTS branch
> with grsec & there is minipli[1] that is going to forward 4.9.X LTS
> branch with grsec.
>
> Would be great to join forces to keep 4.9.X LTS alive while porting
> features upstream.

4.9.* is not a problem, but >=4.10 requires a lot of work, and of
course there is a problem with the KSPP (links kernel.org)

https://archives.gentoo.org/gentoo-hardened/message/e0f9f37be6c5985acd2f19a316a6fee0
Re: Technical repercussions of grsecurity removal [ In reply to ]
Shouldn't go to 4.10+, because it will be too much work.
Best would be to maintain 4.9 LTS and not bother with 4.10 and all that.


On 05/01/2017 04:53 PM, Daniel Cegie?ka wrote:
> 2017-05-01 16:20 GMT+02:00 SK <yandereson@riseup.net>:
>> There is Subgraph that is going to keep maintaining 4.9.X LTS branch
>> with grsec & there is minipli[1] that is going to forward 4.9.X LTS
>> branch with grsec.
>>
>> Would be great to join forces to keep 4.9.X LTS alive while porting
>> features upstream.
> 4.9.* is not a problem, but >=4.10 requires a lot of work, and of
> course there is a problem with the KSPP (links kernel.org)
>
> https://archives.gentoo.org/gentoo-hardened/message/e0f9f37be6c5985acd2f19a316a6fee0
>
Re: Technical repercussions of grsecurity removal [ In reply to ]
https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project

It closes the topic of our discussion.

worth reading:

http://openwall.com/lists/kernel-hardening/2017/05/01/5

http://openwall.com/lists/kernel-hardening/2017/05/02/4

this means:

* KSPP means that keeping PaX for >4.9 will be difficult and painful,
as I pointed out previously
* NSA SELinux instead PAX MPROTECT?


alternatives: RSBAC

* slow, but actively developed:
http://git.rsbac.org/cgi-bin/gitweb.cgi?p=linux-4.9.y.git;a=summary

* produkction ready

* lots of options similar to what is in grsecurity (eg. restricted
chroot in grsec and jail in rsbac):

http://git.rsbac.org/cgi-bin/gitweb.cgi?p=linux-4.9.y.git;a=blob;f=rsbac/Kconfig;h=4a6ae294d41365a5c1757503575074c89ceebb11;hb=HEAD
Re: Technical repercussions of grsecurity removal [ In reply to ]
On Mon, 1 May 2017 09:38:43 +0000
Sven Vermeulen <swift@gentoo.org> wrote:

> The obvious step is indeed to stop further *current* development on
> hardened-sources. I don't know how many additional patchsets are being
> implemented in it (blueness? Zorry?) so I don't know if it means that
> hardened-sources in total is done with or not.

All patches in our current patchset
(hardened-patches-4.9.24-1.extras.tar.bz2) are grsec-related. Most of
them don't even touch the kernel code, but only the Kconfig's. So
unless we manage to maintain PaX, we can indeed kiss hardened-sources
goodbye.

By the way: When switching over to gentoo-sources, please note that it
applies some patches of its own (the genpatches.extras set, whereas
hardened-sources only applies genpatches.base). Historically, this
patchset has sometimes contained some weird (and probably totally
unaudited) code. Currently it only contains two patches which look
mostly safe, but it's probably a good idea to keep an eye on this
patchset (or perhaps to use vanilla-sources?).

Regards,
Luis
Re: Technical repercussions of grsecurity removal [ In reply to ]
2017-05-02 17:28 GMT+02:00 Luis Ressel <aranea@aixah.de>:
> On Mon, 1 May 2017 09:38:43 +0000
> Sven Vermeulen <swift@gentoo.org> wrote:
>
>> The obvious step is indeed to stop further *current* development on
>> hardened-sources. I don't know how many additional patchsets are being
>> implemented in it (blueness? Zorry?) so I don't know if it means that
>> hardened-sources in total is done with or not.
>
> All patches in our current patchset
> (hardened-patches-4.9.24-1.extras.tar.bz2) are grsec-related. Most of
> them don't even touch the kernel code, but only the Kconfig's. So
> unless we manage to maintain PaX, we can indeed kiss hardened-sources
> goodbye.

and, of course :)

grep -r -e paxmark -e pax_kernel /usr/portage/
Re: Technical repercussions of grsecurity removal [ In reply to ]
On Tue, 2 May 2017 17:56:22 +0200
Daniel Cegie?ka <daniel.cegielka@gmail.com> wrote:

> grep -r -e paxmark -e pax_kernel /usr/portage/

pax.?mark actually, since the eclass helper is called pax-mark. :)
I'd hold off on removing those for at least a few months, though.

Regards,
Luis
Re: Technical repercussions of grsecurity removal [ In reply to ]
2017-05-02 18:02 GMT+02:00 Luis Ressel <aranea@aixah.de>:
> On Tue, 2 May 2017 17:56:22 +0200
> Daniel Cegie?ka <daniel.cegielka@gmail.com> wrote:
>
>> grep -r -e paxmark -e pax_kernel /usr/portage/
>
> pax.?mark actually, since the eclass helper is called pax-mark. :)
> I'd hold off on removing those for at least a few months, though.
>

If PAX_MPROTECT returns (KSPP?), then ebuilds will need to be
'paxmarked' again. Years of work and PaX support ends in the trash.
Now we see that there is a new level of security: user trust.
Re: Technical repercussions of grsecurity removal [ In reply to ]
2017.Május 2.(K) 18:59 id?pontban Daniel Cegie?ka ezt írta:
>> pax.?mark actually, since the eclass helper is called pax-mark. :)
>> I'd hold off on removing those for at least a few months, though.
>>
>
> If PAX_MPROTECT returns (KSPP?), then ebuilds will need to be
> 'paxmarked' again. Years of work and PaX support ends in the trash.

I must aggree here. If there will be an alternative implementation marking
may regain its meaning. The same binaries need to be marked in some way or
another. I wouldn't simply dump it unless it would disturb some
functionality.

Regards: Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057
Re: Technical repercussions of grsecurity removal [ In reply to ]
2017-05-02 19:23 GMT+02:00 "Tóth Attila" <atoth@atoth.sote.hu>:
> 2017.Május 2.(K) 18:59 id?pontban Daniel Cegie?ka ezt írta:
>>> pax.?mark actually, since the eclass helper is called pax-mark. :)
>>> I'd hold off on removing those for at least a few months, though.
>>>
>>
>> If PAX_MPROTECT returns (KSPP?), then ebuilds will need to be
>> 'paxmarked' again. Years of work and PaX support ends in the trash.
>
> I must aggree here. If there will be an alternative implementation marking
> may regain its meaning. The same binaries need to be marked in some way or
> another. I wouldn't simply dump it unless it would disturb some
> functionality.

Even if PAX_MPROTECT somehow comes back to the kernel, there is no
guarantee that it will be compatible with current PaX ELF header
(elf_phdata->p_flags & PF_MPROTECT) or PAX_XATTR_FLAGS
(PAX_MPROTECT==0x04000000). Next, the PaX functionality are added to
the kernel gradually: one functionality per patch (eg. PAX_USERCOPY ->
HARDEN_USERCOPY). This means that any future solution will not be
compatible with current PaX support. Again: years of work and PaX
support ends in the trash.
Re: Technical repercussions of grsecurity removal [ In reply to ]
Hi!

On Tue, May 02, 2017 at 09:58:18PM +0200, Daniel Cegie?ka wrote:
> This means that any future solution will not be compatible with current
> PaX support.

It doesn't means that. That may happens, or not - if someone will bother
about compatibility, for example.

I also think it makes sense to keep paxmarking in ebuilds, for now.
If not for technical reasons, then just to avoid adding more damage.
GrSec/PaX is not going anywhere, at least not immediately, there are a lot
of systems which still use hardened-sources and may continue using current
versions for long enough time - and they'll need that paxmarking for
current and new versions of ebuilds. Plus there is a non-zero chance next
solution will replace GrSec/PaX in more or less compatible way. And thus
until it became clear next solution doesn't require similar paxmarking at
same places or supporting paxmarking in existing ebuilds will require any
noticeable effort - there is no good reason to destroy something what just
works now.

> Again: years of work and PaX support ends in the trash.

Yeah, we already know you feel it this way. Any reason to repeat this
again and again? How this will improve anything?

--
WBR, Alex.
Re: Technical repercussions of grsecurity removal [ In reply to ]
On 170502-10:28+0200, Daniel Cegie?ka wrote:
> https://wiki.gentoo.org/wiki/Hardened/Hardened_Kernel_Project
>
> It closes the topic of our discussion.
>
And I read all the discussion in gentoo-hardened in regard.

First, I'm a user[1], and I'm trying to continue to keep safe and secure
as I used to be with grsec/PaX.

I figured out only yesterday about this almost two weeks old news, and I
guess the then 10+ days old (slightly) unmaintained kernel
4.9.24-hardened (and there won't be any updates, correct?), may have
contributed to my woes[2]:

# ls -ABRgo /usr/portage/sys-kernel/hardened-sources/
...
-rw-r--r-- 1 47449 2016-12-17 02:21 ChangeLog
...
-rw-r--r-- 1 1316 2017-04-22 18:18 hardened-sources-4.9.24.ebuild
...
#

And really since late in 2016 no more entries in the Changelog. Pls.
note that I'm only stating the facts, not complaining.

I really wish I learn myself and be able to contribute; acually I have
occasinally contributed, marginally, to the hardened project, with
testing.

> worth reading:
>
> http://openwall.com/lists/kernel-hardening/2017/05/01/5
>
> http://openwall.com/lists/kernel-hardening/2017/05/02/4

And these should not be missed:

It looks like there will be no more public versions of PaX and Grsec
http://openwall.com/lists/kernel-hardening/2017/05/04/20
( Shawn's collection of links there are an eye-opener, esp. this one
link which, to me, feels like sacrilege:
https://mjg59.dreamwidth.org/39546.html
about Karen Sandler, the executive director of the Software Freedom
Conservancy, by sly means prevented to stand for LF board )

and:
< same subject >
http://openwall.com/lists/kernel-hardening/2017/05/02/14
( where find what "is... unappealing." )

> this means:
>
> * KSPP means that keeping PaX for >4.9 will be difficult and painful,
> as I pointed out previously

> * NSA SELinux instead PAX MPROTECT?
I hope this is a joke. It looks like one, at first sight, but there are
half a dozen "NSA SELinux" instances to be found in the latest
hardened-sources.

# grep 'NSA SE' /usr/src/linux/security/selinux/Kconfig
bool "NSA SELinux Support"
...
#
(where linux is a hardened-sources installation)

If hardened would be down to SELinux, I wouldn't be hardening any more.

> alternatives: RSBAC
>
...

But I saw the other link that gives me some hope:

Unofficial forward ports of the last publicly available grsecurity patch
https://github.com/minipli/linux-unofficial_grsec/tree/linux-4.9.x-unofficial_grsec

which I cloned into my machine. (And I have just spent hours trying to
fix an ebuild in my custom overlay and install it in my machine, to no
avail so far, and I'm at the end of my forbearance... A little more below.)

And I wonder:

1) Are there any guides for non-programmers how to install the:

Merge tag 'v4.9.26' into linux-4.9.x-unofficial_grsec
https://github.com/minipli/linux-unofficial_grsec/commit/bb9fb983874810ca4167430508e06975af700824?diff=unified

UPDATE (at proofreading time: Matheus, thanks! You just PGP-signed the
new tag [3], reader, skip 16 lines )

2) How can I check the integrity? I can:

$ git tag --verify v4.9.26
object d071951e08ee23cd725c2336d7ab4582bb93b0af
type commit
tag v4.9.26
tagger Greg Kroah-Hartman <gregkh@linuxfoundation.org> 1493825816 -0700
...
$

but I can not verify Mathias Krause's commit. Pls. minipli, can you
start PGP-signing... [cut more text, because you have :) ]

(Continue reading, isues left here, this is the "little more below"
I mentioned above.)

The README.md is plain readme from the kernel, no mention of grsec at
all...

Where do I get some tips how to install? I do have the git sources, they
verify fine... I will, hopefully, keep strong and keep trying, but I'm
not so very sure I am able to craft an ebuild that would work and that
would install with the local git linux-unofficial_grsec repo...

I suspect the [2] below was because my kernel wasn't updated... and I do
feel a little insecure at this time...

---
[1] but I can understand the issues the developers have. I have some
understanding of programming, and the politics with and around FOSS
is easy to understand, given time and info.

[2] Strange script planted with Bash
https://www.croatiafidelis.hr/foss/cap/cap-170504-strange-bash/
and:
Inconsistent behavior in my Gentoo OS instance
https://lists.gt.net/gentoo/user/325985#325985

[3] $ git tag --verify v4.9.26-unofficial_grsec
object bb9fb983874810ca4167430508e06975af700824
type commit
tag v4.9.26-unofficial_grsec
tagger Mathias Krause <minipli@googlemail.com> 1494181910 +0200

This is the unofficial forward port of grsecurity-3.1-4.9.24-201704252333.patch to v4.9.26
gpg: Signature made Sun 07 May 2017 20:32:02 CEST
gpg: using RSA key 7585399992435BA4
gpg: Good signature from "Mathias Krause <minipli@googlemail.com>" [unknown]
...
Primary key fingerprint: 7629 8B5B B60E DAD2 1B36 2E66 7585 3999 9243 5BA4

Regards!
--
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr
Re: Technical repercussions of grsecurity removal [ In reply to ]
Hi,

I don't have much to add, but I'd like to clear two misunderstandings
here:

On Mon, 8 May 2017 20:08:07 +0200
Miroslav Rovis <miro.rovis@croatiafidelis.hr> wrote:

> And really since late in 2016 no more entries in the Changelog. Pls.
> note that I'm only stating the facts, not complaining.

AFAIK the Changelogs aren't updated anymore (in the whole gentoo tree).

> > * NSA SELinux instead PAX MPROTECT?
> I hope this is a joke. It looks like one, at first sight, but there
> are half a dozen "NSA SELinux" instances to be found in the latest
> hardened-sources.
>
> # grep 'NSA SE' /usr/src/linux/security/selinux/Kconfig
> bool "NSA SELinux Support"
> ...
> #
> (where linux is a hardened-sources installation)
>
> If hardened would be down to SELinux, I wouldn't be hardening any
> more.

SELinux isn't a patch applied by hardened-sources, it's a subsystem of
the mainline kernel. grsec was really the only significant difference
between hardened-sources and gentoo-sources.

Regards,
Luis
Re: Technical repercussions of grsecurity removal [ In reply to ]
On 8 May 2017 at 20:08, Miroslav Rovis <miro.rovis@croatiafidelis.hr> wrote:
> [...]
> But I saw the other link that gives me some hope:
>
> Unofficial forward ports of the last publicly available grsecurity patch
> https://github.com/minipli/linux-unofficial_grsec/tree/linux-4.9.x-unofficial_grsec
>
> which I cloned into my machine. (And I have just spent hours trying to
> fix an ebuild in my custom overlay and install it in my machine, to no
> avail so far, and I'm at the end of my forbearance... A little more below.)
>
> And I wonder:
>
> 1) Are there any guides for non-programmers how to install the:
>
> Merge tag 'v4.9.26' into linux-4.9.x-unofficial_grsec
> https://github.com/minipli/linux-unofficial_grsec/commit/bb9fb983874810ca4167430508e06975af700824?diff=unified

See below.

> [...]
>
> 2) How can I check the integrity? I can:

You figured that one already ;)

> [...]
> The README.md is plain readme from the kernel, no mention of grsec at
> all...

...as it used to be the case for the official grsec patch. So nothing
has changed here. ;) But I can understand your concerns. If you're
used to getting a patch and have to use a git repo now, it's not
intuitive on *how* to make use of it. But, again, see below...

>
> Where do I get some tips how to install? I do have the git sources, they
> verify fine... I will, hopefully, keep strong and keep trying, but I'm
> not so very sure I am able to craft an ebuild that would work and that
> would install with the local git linux-unofficial_grsec repo...

I'm not familiar with the gentoo ebuild based package system but I
guess patches integrate more smoothly than git repositories do. So
here's how you generate a patch for the unofficial port for v4.9.27
(just pushed ;):

$ git remote update
[update log foo]
$ git diff v4.9.27..v4.9.27-unofficial_grsec > ~/unofficial_grsec-v4.9.27.diff

If you don't want to clone the git repo you can fetch the patch
directly via the github web interface:

$ curl https://github.com/minipli/linux-unofficial_grsec/compare/v4.9.27...v4.9.27-unofficial_grsec.diff
> ~/unofficial_grsec-v4.9.27.diff

The pattern should be intuitive: just change "v4.9.27" for the kernel
version you want to get a patch for (v4.9.25 to v4.9.27 so far).

The generated patch can be applied on a vanilla Linux v4.9.27 as usual
to generate the unofficial grsec kernel.

I hope this helps!

Cheers,
Mathias
Re: Technical repercussions of grsecurity removal [ In reply to ]
(thanks also to Luis Ressel for clarifications in the other email)

(I'm only top posting because this reply of mine has no particularities
to place it btwn any lines further below. Otherwise, I don't top post.)

Mathias, I only wish to thank you for the quick reply and the tips
below. And all my hopes are in you and your team/your contributors
(I'm sure there will be great libre people congregating on
linux-unofficial_grsec these days and weeks ahead, and longer). Make it
as libre as possible! Keep fixing the kernel that Mr Linux wouldn't make
secure... Yes, he and his comrades from big business caused this rift.
I don't blame spender and PaX Team either....

And about ebuild making, I'll try my best and if I don't break apart in
unsuccessful trying, I'll be back with an ebuild to discuss. Or if
anybody from Gentoo hardened cares, they can teach us how to do the
Gentoo details.

(no more new text, only my signature in bottom)

On 170508-22:07+0200, Mathias Krause wrote:
> On 8 May 2017 at 20:08, Miroslav Rovis <miro.rovis@croatiafidelis.hr> wrote:
> > [...]
> > But I saw the other link that gives me some hope:
> >
> > Unofficial forward ports of the last publicly available grsecurity patch
> > https://github.com/minipli/linux-unofficial_grsec/tree/linux-4.9.x-unofficial_grsec
> >
> > which I cloned into my machine. (And I have just spent hours trying to
> > fix an ebuild in my custom overlay and install it in my machine, to no
> > avail so far, and I'm at the end of my forbearance... A little more below.)
> >
> > And I wonder:
> >
> > 1) Are there any guides for non-programmers how to install the:
> >
> > Merge tag 'v4.9.26' into linux-4.9.x-unofficial_grsec
> > https://github.com/minipli/linux-unofficial_grsec/commit/bb9fb983874810ca4167430508e06975af700824?diff=unified
>
> See below.
>
> > [...]
> >
> > 2) How can I check the integrity? I can:
>
> You figured that one already ;)
>
> > [...]
> > The README.md is plain readme from the kernel, no mention of grsec at
> > all...
>
> ...as it used to be the case for the official grsec patch. So nothing
> has changed here. ;) But I can understand your concerns. If you're
> used to getting a patch and have to use a git repo now, it's not
> intuitive on *how* to make use of it. But, again, see below...
>
> >
> > Where do I get some tips how to install? I do have the git sources, they
> > verify fine... I will, hopefully, keep strong and keep trying, but I'm
> > not so very sure I am able to craft an ebuild that would work and that
> > would install with the local git linux-unofficial_grsec repo...
>
> I'm not familiar with the gentoo ebuild based package system but I
> guess patches integrate more smoothly than git repositories do. So
> here's how you generate a patch for the unofficial port for v4.9.27
> (just pushed ;):
>
> $ git remote update
> [update log foo]
> $ git diff v4.9.27..v4.9.27-unofficial_grsec > ~/unofficial_grsec-v4.9.27.diff
>
> If you don't want to clone the git repo you can fetch the patch
> directly via the github web interface:
>
> $ curl https://github.com/minipli/linux-unofficial_grsec/compare/v4.9.27...v4.9.27-unofficial_grsec.diff
> > ~/unofficial_grsec-v4.9.27.diff
>
> The pattern should be intuitive: just change "v4.9.27" for the kernel
> version you want to get a patch for (v4.9.25 to v4.9.27 so far).
>
> The generated patch can be applied on a vanilla Linux v4.9.27 as usual
> to generate the unofficial grsec kernel.
>
> I hope this helps!
>
> Cheers,
> Mathias

Regards!
--
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr
Re: Technical repercussions of grsecurity removal [ In reply to ]
On Mon, 1 May 2017 13:58:08 +0000 Sven Vermeulen wrote:
> On Mon, May 01, 2017 at 01:28:54PM +0300, Andrew Savchenko wrote:
> > > The obvious step is indeed to stop further *current* development on
> > > hardened-sources.
> >
> > Why not support hardened-sources while corresponding vanilla
> > kernels are still supported? E.g. 4.9 is a longterm branch, so we
> > should be able to keep hardened-sources-4.9* up-to-date with
> > vanilla bugfixes. This will give a nice transition period for
> > hardened users.
>
> Transition to what exactly?

It doesn't really matter. Something will come up, but we need to
provide users smooth experience before then. Supporting 4.9 looks
like a good solution here.

Most likely KSPP project will come up, they are doing a good job:
bringing security features upstream fixing bugs in PaX code during
the process [1]. This is what PaX should have done long time ago,
they were even offered CII grant for this job, but refused [2].

[1] http://openwall.com/lists/kernel-hardening/2017/05/02/4
[2] https://lists.coreinfrastructure.org/pipermail/cii-discuss/2015-August/000003.html

Best regards,
Andrew Savchenko
Re: Technical repercussions of grsecurity removal [ In reply to ]
On 170508-22:49+0200, Miroslav Rovis wrote:
> ...
> I'll be back with an ebuild to discuss.
> ...
> On 170508-22:07+0200, Mathias Krause wrote:
> > On 8 May 2017 at 20:08, Miroslav Rovis <miro.rovis@croatiafidelis.hr> wrote:
...
> > > Unofficial forward ports of the last publicly available grsecurity patch
> > > https://github.com/minipli/linux-unofficial_grsec/tree/linux-4.9.x-unofficial_grsec
> > >
> > > which I cloned into my machine.
...
> > ...as it used to be the case for the official grsec patch. So nothing
> > has changed here. ;) But I can understand your concerns. If you're
> > used to getting a patch and have to use a git repo now, it's not
> > intuitive on *how* to make use of it. But, again, see below...
...
> > I'm not familiar with the gentoo ebuild based package system but I
> > guess patches integrate more smoothly than git repositories do. So
> > here's how you generate a patch for the unofficial port for v4.9.27
> > (just pushed ;):
> >
> > $ git remote update
I'm used to doing:
$ git pull
(and I think it did the same, but I need to do it all over, more below,
and in my next try I'll to 'git remote update')
> > [update log foo]
> > $ git diff v4.9.27..v4.9.27-unofficial_grsec > ~/unofficial_grsec-v4.9.27.diff
Yes, that is how I got the grsec patch. I named it:
4420_grsecurity-3.1-4.9.27-201705082100.patch

This is what I did by comparison. The 4.9.24/ is gotten by:
tar xf /usr/portage/distfiles/hardened-patches-4.9.24-1.extras.tar.bz2

and so I created:
mkdir 4.9.27/, placed the content of the old 4.9.24/, except not the old
patch, but the new I placed in it. See:

# ls -ABRgo 4.9.24/
4.9.24/:
total 9380
-rw-r--r-- 1 2003 2017-04-22 17:58 0000_README
-rw-r--r-- 1 101631 2017-04-22 17:58 1023_linux-4.9.24.patch
-rw-r--r-- 1 9451813 2017-04-22 17:38 4420_grsecurity-3.1-4.9.24-201704220732.patch
-rw-r--r-- 1 665 2016-11-10 01:55 4425_grsec_remove_EI_PAX.patch
-rw-r--r-- 1 1359 2017-01-01 18:15 4426_default_XATTR_PAX_FLAGS.patch
-rw-r--r-- 1 1444 2017-02-15 14:14 4427_force_XATTR_PAX_tmpfs.patch
-rw-r--r-- 1 303 2015-08-14 08:04 4430_grsec-remove-localversion-grsec.patch
-rw-r--r-- 1 1528 2016-08-14 12:16 4435_grsec-mute-warnings.patch
-rw-r--r-- 1 641 2015-08-14 08:04 4440_grsec-remove-protected-paths.patch
-rw-r--r-- 1 4184 2016-12-14 13:33 4450_grsec-kconfig-default-gids.patch
-rw-r--r-- 1 2616 2016-12-14 13:32 4465_selinux-avc_audit-log-curr_ip.patch
-rw-r--r-- 1 2553 2017-02-15 14:14 4470_disable-compat_vdso.patch
-rw-r--r-- 1 1467 2017-01-16 22:22 4475_emutramp_default_on.patch
#

# ls -ABRgo 4.9.27/
4.9.27/:
total 9184
-rw-r--r-- 1 2003 2017-04-22 17:58 0000_README
-rw-r--r-- 1 9352316 2017-05-08 23:47 4420_grsecurity-3.1-4.9.27-201705082100.patch
-rw-r--r-- 1 665 2016-11-10 01:55 4425_grsec_remove_EI_PAX.patch
-rw-r--r-- 1 1359 2017-01-01 18:15 4426_default_XATTR_PAX_FLAGS.patch
-rw-r--r-- 1 1444 2017-02-15 14:14 4427_force_XATTR_PAX_tmpfs.patch
-rw-r--r-- 1 303 2015-08-14 08:04 4430_grsec-remove-localversion-grsec.patch
-rw-r--r-- 1 1528 2016-08-14 12:16 4435_grsec-mute-warnings.patch
-rw-r--r-- 1 641 2015-08-14 08:04 4440_grsec-remove-protected-paths.patch
-rw-r--r-- 1 4184 2016-12-14 13:33 4450_grsec-kconfig-default-gids.patch
-rw-r--r-- 1 2616 2016-12-14 13:32 4465_selinux-avc_audit-log-curr_ip.patch
-rw-r--r-- 1 2553 2017-02-15 14:14 4470_disable-compat_vdso.patch
-rw-r--r-- 1 1467 2017-01-16 22:22 4475_emutramp_default_on.patch
#

And then I issued:

tar cjf /usr/portage/distfiles/hardened-patches-4.9.27-1.extras.tar.bz2 4.9.27/

Similarly, looking up what
tar xf /usr/portage/distfiles/genpatches-4.9-24.base.tar.xz
decompresses into, actually it needs a folder created before it does so:
tar xf /usr/portage/distfiles/genpatches-4.9-24.base.tar.xz -C linux
, I copied it to
[.[. STOP, I found why the below, exactly because I didn't descend in that
directory when I created, be see further below ]]

However (and also logs are to follow), the patching didn't go right:
# find /usr/src/linux/ -name '*.rej'
/usr/src/linux/arch/x86/mm/init.c.rej
/usr/src/linux/arch/x86/entry/entry_32.S.rej
/usr/src/linux/mm/nommu.c.rej
/usr/src/linux/mm/memory.c.rej
/usr/src/linux/net/core/neighbour.c.rej
/usr/src/linux/net/packet/af_packet.c.rej
/usr/src/linux/net/unix/af_unix.c.rej
/usr/src/linux/net/mpls/af_mpls.c.rej
/usr/src/linux/include/linux/sched.h.rej
/usr/src/linux/include/linux/capability.h.rej
/usr/src/linux/include/linux/mm.h.rej
/usr/src/linux/fs/namespace.c.rej
/usr/src/linux/fs/exec.c.rej
/usr/src/linux/fs/splice.c.rej
/usr/src/linux/drivers/char/mem.c.rej
/usr/src/linux/drivers/hv/hv.c.rej
/usr/src/linux/kernel/ptrace.c.rej
/usr/src/linux/kernel/cpu.c.rej
#

So the above happened, but (and this is the "further belows") it
happened because, here's the paste:

# tar tf /usr/portage/distfiles/genpatches-4.9-27.base.tar.xz | head
linux/
linux/1012_linux-4.9.13.patch
linux/1022_linux-4.9.23.patch
linux/1008_linux-4.9.9.patch
linux/1005_linux-4.9.6.patch
linux/1011_linux-4.9.12.patch
linux/2900_dev-root-proc-mount-fix.patch
linux/1009_linux-4.9.10.patch
linux/1024_linux-4.9.25.patch
linux/1016_linux-4.9.17.patch
# tar tf /usr/portage/distfiles/genpatches-4.9-24.base.tar.xz | head
./0000_README
./1000_linux-4.9.1.patch
./1001_linux-4.9.2.patch
./1002_linux-4.9.3.patch
./1003_linux-4.9.4.patch
./1004_linux-4.9.5.patch
./1005_linux-4.9.6.patch
./1006_linux-4.9.7.patch
./1007_linux-4.9.8.patch
./1008_linux-4.9.9.patch
#

# diff linux linux-4.9-24/
Only in linux: 1023_linux-4.9.24.patch
Only in linux: 1024_linux-4.9.25.patch
Only in linux: 1025_linux-4.9.26.patch
Only in linux: 1026_linux-4.9.27.patch
#

And I'm sorry for mixed-up reporting, but I will leave it like this,
because I need to go to sleep, can't improve it...

And there are still issues.

With the ebuild attached:

hardened-sources-4.9.27.ebuild

the kernel installs, but upon "make menuconfig" it looks like this:


.config - Linux/x86 4.9.1-hardened Kernel Configuration
????????????????????????????????????????????????????????????????????????????????????????????
????????????????????? Linux/x86 4.9.1-hardened Kernel Configuration ?????????????????????
? Arrow keys navigate the menu. <Enter> selects submenus ---> (or empty subme
...

And also the compiling fails. But first the *.rej. Less than the
previous time! See:

# find /usr/src/linux/ -name '*.rej'
/usr/src/linux/arch/x86/mm/init.c.rej
/usr/src/linux/arch/x86/entry/entry_32.S.rej
/usr/src/linux/net/core/neighbour.c.rej
/usr/src/linux/net/packet/af_packet.c.rej
/usr/src/linux/net/unix/af_unix.c.rej
/usr/src/linux/net/mpls/af_mpls.c.rej
/usr/src/linux/fs/namespace.c.rej
/usr/src/linux/drivers/char/mem.c.rej
/usr/src/linux/drivers/hv/hv.c.rej
/usr/src/linux/kernel/cpu.c.rej
#

And here's how it failed:

# make && make install &
HOSTCC scripts/kconfig/conf.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --silentoldconfig Kconfig
HOSTCC arch/x86/tools/relocs_32.o
HOSTCC arch/x86/tools/relocs_64.o
HOSTLD arch/x86/tools/relocs
CHK include/config/kernel.release
UPD include/config/kernel.release
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
UPD include/generated/utsrelease.h
HOSTCXX -fPIC scripts/gcc-plugins/rap_plugin/rap_plugin.o
scripts/gcc-plugins/rap_plugin/rap_plugin.c: In function ‘bool rap_cgraph_indirectly_callable(cgraph_node_ptr)’:
scripts/gcc-plugins/rap_plugin/rap_plugin.c:132:87: error: ‘cgraph_for_node_and_aliases’ was not declared in this scope
return cgraph_for_node_and_aliases(node, __rap_cgraph_indirectly_callable, NULL, true);
^
make[2]: *** [scripts/Makefile.host:158: scripts/gcc-plugins/rap_plugin/rap_plugin.o] Error 1
make[1]: *** [scripts/Makefile.build:544: scripts/gcc-plugins/rap_plugin] Error 2
make: *** [scripts/Makefile.gcc-plugins:129: gcc-plugins] Error 2

#

Good night. In case somebody wants to look up why it failed, and should
I ask Mathias or file a bug, or something else, here is also my emerge
--info, gzip'd:

Good night!
--
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr
Re: Technical repercussions of grsecurity removal [ In reply to ]
2017.Május 8.(H) 23:12 id?pontban Andrew Savchenko ezt írta:
> Most likely KSPP project will come up, they are doing a good job:
> bringing security features upstream fixing bugs in PaX code during
> the process [1]. This is what PaX should have done long time ago,
> they were even offered CII grant for this job, but refused [2].
>
> [1] http://openwall.com/lists/kernel-hardening/2017/05/02/4
> [2]
> https://lists.coreinfrastructure.org/pipermail/cii-discuss/2015-August/000003.html

Just as a follow-up regarding the argument between KSPP and Grsecurity.
Please take a look at on the reply of PaxTeam postend on the openwall
mailing list:
http://openwall.com/lists/kernel-hardening/2017/05/11/2

Pá:
Attila
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

1 2  View All