[gentoo-hardened] Technical repercussions of grsecurity removal

[gentoo-hardened] Technical repercussions of grsecurity removal

[Sven Vermeulen]

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: [gentoo-hardened] Technical repercussions of grsecurity removal

[Sven Vermeulen]

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: [gentoo-hardened] Technical repercussions of grsecurity removal

[Daniel Cegiełka]

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: [gentoo-hardened] Technical repercussions of grsecurity removal

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-hardened] Technical repercussions of grsecurity removal

[Daniel Cegiełka]

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: [gentoo-hardened] Technical repercussions of grsecurity removal

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-hardened] Technical repercussions of grsecurity removal

[Sven Vermeulen]

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: [gentoo-hardened] Technical repercussions of grsecurity removal

[SK]

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: [gentoo-hardened] Technical repercussions of grsecurity removal

[Daniel Cegiełka]

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: [gentoo-hardened] Technical repercussions of grsecurity removal

[SK]

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: [gentoo-hardened] Technical repercussions of grsecurity removal

[Daniel Cegiełka]

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: [gentoo-hardened] Technical repercussions of grsecurity removal

[Miroslav Rovis]

[-- Attachment #1: Type: text/plain, Size: 5171 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-hardened] Technical repercussions of grsecurity removal

[Luis Ressel]

[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-hardened] Technical repercussions of grsecurity removal

[Mathias Krause]

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: [gentoo-hardened] Technical repercussions of grsecurity removal

[Miroslav Rovis]

[-- Attachment #1: Type: text/plain, Size: 3690 bytes --]

(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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-hardened] Technical repercussions of grsecurity removal

[Miroslav Rovis]

[-- Attachment #1.1: Type: text/plain, Size: 8742 bytes --]

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

[-- Attachment #1.2: hardened-sources-4.9.27.ebuild --]
[-- Type: text/plain, Size: 1332 bytes --]

# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

EAPI="5"

ETYPE="sources"
K_WANT_GENPATCHES="base"
K_GENPATCHES_VER="27"
K_DEBLOB_AVAILABLE="0"
K_FROM_GIT="27"

inherit kernel-2
detect_version

HGPV="${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}-1"
HGPV_URI="http://dev.gentoo.org/~blueness/hardened-sources/hardened-patches/hardened-patches-${HGPV}.extras.tar.bz2"
SRC_URI="${KERNEL_URI} ${HGPV_URI} ${GENPATCHES_URI} ${ARCH_URI}"

UNIPATCH_LIST="${DISTDIR}/hardened-patches-${HGPV}.extras.tar.bz2"
UNIPATCH_EXCLUDE="
	1500_XATTR_USER_PREFIX.patch
	1520_CVE-2017-6074-dccp-skb-freeing-fix.patch
	2900_dev-root-proc-mount-fix.patch"

DESCRIPTION="Hardened kernel sources (kernel series ${KV_MAJOR}.${KV_MINOR})"
HOMEPAGE="http://www.gentoo.org/proj/en/hardened/"
IUSE="deblob"

KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~ppc ~ppc64 ~sparc ~x86"

RDEPEND=">=sys-devel/gcc-4.5"

pkg_postinst() {
	kernel-2_pkg_postinst

	local GRADM_COMPAT="sys-apps/gradm-3.1*"

	ewarn
	ewarn "Users of grsecurity's RBAC system must ensure they are using"
	ewarn "${GRADM_COMPAT}, which is compatible with ${PF}."
	ewarn "It is strongly recommended that the following command is issued"
	ewarn "prior to booting a ${PF} kernel for the first time:"
	ewarn
	ewarn "emerge -na =${GRADM_COMPAT}"
	ewarn
}

[-- Attachment #1.3: emerge--info.gz --]
[-- Type: application/octet-stream, Size: 6584 bytes --]

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-hardened] Unofficial grsec kernel install WAS: Technical repercussions of grsecurity removal

[Miroslav Rovis]

[-- Attachment #1.1: Type: text/plain, Size: 4622 bytes --]

On 170509-01:31+0200, Miroslav Rovis wrote:
> 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.
...

I managed to install:

$ uname -r
4.9.27-hardened-unofficial_grsec-170509_14
$

The issues I had were trivial, only some familiarizing with the methods.

So far, booting into the new kernel, and deployment, all is fine,
absolutely regular (*so far*).

If anybody would need it, I can try and make a step by step notes the
next time I do the building in my Air-Gapped, which is soon. Much
later will be harder to reproduce the steps correctly without actually
doing it.

Here's my ebuild, and the genpatches and hardened-patches listing, if it
helps (often developers discuss here, which is fine, but I'm writing
this for users).

hardened-sources-4.9.27.ebuild

# ls -ABRgo /usr/portage/distfiles/{hardened-patches-4.9.27-1.extras.tar.bz2,genpatches-4.9-27.base.tar.xz}
-rw-r--r-- 1  536200 2017-05-09 13:02 /usr/portage/distfiles/genpatches-4.9-27.base.tar.xz
-rw-r--r-- 1 1997214 2017-05-09 14:08 /usr/portage/distfiles/hardened-patches-4.9.27-1.extras.tar.bz2
#

ls -ABRgo genpatches-4.9-27/
genpatches-4.9-27/:
total 2432
-rw-r--r-- 1   5412 2017-04-18 14:29 0000_README
-rw-r--r-- 1 114367 2017-04-18 14:29 1000_linux-4.9.1.patch
-rw-r--r-- 1 141140 2017-04-18 14:29 1001_linux-4.9.2.patch
-rw-r--r-- 1 264856 2017-04-18 14:29 1002_linux-4.9.3.patch
-rw-r--r-- 1  58683 2017-04-18 14:29 1003_linux-4.9.4.patch
-rw-r--r-- 1 177665 2017-04-18 14:29 1004_linux-4.9.5.patch
-rw-r--r-- 1 149694 2017-04-18 14:29 1005_linux-4.9.6.patch
-rw-r--r-- 1  71811 2017-04-18 14:29 1006_linux-4.9.7.patch
-rw-r--r-- 1  64550 2017-04-18 14:29 1007_linux-4.9.8.patch
-rw-r--r-- 1  78333 2017-04-18 14:29 1008_linux-4.9.9.patch
-rw-r--r-- 1  73914 2017-04-18 14:29 1009_linux-4.9.10.patch
-rw-r--r-- 1  60460 2017-04-18 14:29 1010_linux-4.9.11.patch
-rw-r--r-- 1  21015 2017-04-18 14:29 1011_linux-4.9.12.patch
-rw-r--r-- 1  34344 2017-04-18 14:29 1012_linux-4.9.13.patch
-rw-r--r-- 1 220480 2017-04-18 14:29 1013_linux-4.9.14.patch
-rw-r--r-- 1  96906 2017-04-18 14:29 1014_linux-4.9.15.patch
-rw-r--r-- 1  52098 2017-04-18 14:29 1015_linux-4.9.16.patch
-rw-r--r-- 1 195764 2017-04-18 14:29 1016_linux-4.9.17.patch
-rw-r--r-- 1  29223 2017-04-18 14:29 1017_linux-4.9.18.patch
-rw-r--r-- 1 101849 2017-04-18 14:29 1018_linux-4.9.19.patch
-rw-r--r-- 1  17310 2017-04-18 14:29 1019_linux-4.9.20.patch
-rw-r--r-- 1 148261 2017-04-18 14:29 1020_linux-4.9.21.patch
-rw-r--r-- 1 207889 2017-04-18 14:29 1021_linux-4.9.22.patch
-rw-r--r-- 1  40950 2017-04-18 14:29 1022_linux-4.9.23.patch
-rw-r--r-- 1   2369 2017-04-18 14:29 1500_XATTR_USER_PREFIX.patch
-rw-r--r-- 1    717 2017-01-12 13:09 1510_fs-enable-link-security-restrictions-by-default.patch
-rw-r--r-- 1   3056 2017-04-18 14:29 2300_enable-poweroff-on-Mac-Pro-11.patch
-rw-r--r-- 1   1205 2017-04-18 12:46 2900_dev-root-proc-mount-fix.patch

ls -ABRgo 4.9.27/
4.9.27/:
total 9404
-rw-r--r-- 1    2240 2017-05-09 13:04 0000_README
-rw-r--r-- 1  101631 2017-04-22 17:58 1023_linux-4.9.24.patch
-rw-r--r-- 1   25435 2017-05-09 14:08 1024_linux-4.9.25.patch
-rw-r--r-- 1   57956 2017-05-09 14:08 1025_linux-4.9.26.patch
-rw-r--r-- 1   29538 2017-05-09 14:07 1026_linux-4.9.27.patch
-rw-r--r-- 1 9352316 2017-05-09 11:57 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

Regards!
-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr

[-- Attachment #1.2: hardened-sources-4.9.27.ebuild --]
[-- Type: text/plain, Size: 1360 bytes --]

# Copyright 1999-2017 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2

EAPI="5"

ETYPE="sources"
K_WANT_GENPATCHES="base"
K_GENPATCHES_VER="27"
K_DEBLOB_AVAILABLE="0"

inherit kernel-2
detect_version

HGPV="${KV_MAJOR}.${KV_MINOR}.${KV_PATCH}-1"
HGPV_URI="http://dev.gentoo.org/~blueness/hardened-sources/hardened-patches/hardened-patches-${HGPV}.extras.tar.bz2"
SRC_URI="${KERNEL_URI} ${HGPV_URI} ${GENPATCHES_URI} ${ARCH_URI}"

UNIPATCH_LIST="${DISTDIR}/hardened-patches-${HGPV}.extras.tar.bz2"
UNIPATCH_EXCLUDE="
	1500_XATTR_USER_PREFIX.patch
	1520_CVE-2017-6074-dccp-skb-freeing-fix.patch
	2900_dev-root-proc-mount-fix.patch
	4430_grsec-remove-localversion-grsec.patch"

DESCRIPTION="Hardened kernel sources (kernel series ${KV_MAJOR}.${KV_MINOR})"
HOMEPAGE="http://www.gentoo.org/proj/en/hardened/"
IUSE="deblob"

KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~ppc ~ppc64 ~sparc ~x86"

RDEPEND=">=sys-devel/gcc-4.5"

pkg_postinst() {
	kernel-2_pkg_postinst

	local GRADM_COMPAT="sys-apps/gradm-3.1*"

	ewarn
	ewarn "Users of grsecurity's RBAC system must ensure they are using"
	ewarn "${GRADM_COMPAT}, which is compatible with ${PF}."
	ewarn "It is strongly recommended that the following command is issued"
	ewarn "prior to booting a ${PF} kernel for the first time:"
	ewarn
	ewarn "emerge -na =${GRADM_COMPAT}"
	ewarn
}

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-hardened] Technical repercussions of grsecurity removal

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1176 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-hardened] Technical repercussions of grsecurity removal

["Tóth Attila"]

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

Re: [gentoo-hardened] Technical repercussions of grsecurity removal

[Alex Efros]

Hi!

On Fri, May 12, 2017 at 09:10:43PM +0200, "Tóth Attila" wrote:
> 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

What's for? It's pointless. Only very few people are really interested
(i.e. not just curious) in knowing who is paid by which company for doing
what, who makes more real bugs, and who lies about something.

The important questions about how to keep current level of protection for
individual/small business users and how users of some distributions like
Gentoo/Ubuntu/Android can be protected with GrSec/PaX are still unanswered.

While large companies may buy subscription for GrSec/PaX the mentioned
above categories of users can't (correct me if I'm wrong, please) - so
effectively the change in GrSec policy makes harm and punish mostly these
categories of users. If that's real GrSec/PaX goal - it's very sad but
they probably have rights to do this (except their public reasoning
doesn't match what they actually do, so probably there are some unsaid
reasoning exists too), but if it's not their real goal - then they
probably should provide some options for these categories of users too.

-- 
			WBR, Alex.

Re: [gentoo-hardened] Technical repercussions of grsecurity removal

[Max R.D. Parmer]

On Fri, May 12, 2017, at 16:38, Alex Efros wrote:
> Hi!
> 
> On Fri, May 12, 2017 at 09:10:43PM +0200, "Tóth Attila" wrote:
> > 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
> 
> What's for? It's pointless. Only very few people are really interested
> (i.e. not just curious) in knowing who is paid by which company for doing
> what, who makes more real bugs, and who lies about something.
> 
> The important questions about how to keep current level of protection for
> individual/small business users and how users of some distributions like
> Gentoo/Ubuntu/Android can be protected with GrSec/PaX are still
> unanswered.
> 
> While large companies may buy subscription for GrSec/PaX the mentioned
> above categories of users can't (correct me if I'm wrong, please) - so
> effectively the change in GrSec policy makes harm and punish mostly these
> categories of users. If that's real GrSec/PaX goal - it's very sad but
> they probably have rights to do this (except their public reasoning
> doesn't match what they actually do, so probably there are some unsaid
> reasoning exists too), but if it's not their real goal - then they
> probably should provide some options for these categories of users too.
> 
> -- 
> 			WBR, Alex.

Individuals can certainly request a quote -- I did -- their director of
sales is very patient, considerate and accommodating. Unfortunately the
price is quite a bit more than I can personally afford at present.


I don't personally doubt PaXteam/Spenders stated reasoning. It appears
they've encountered a quite aggravating situation with what may amount
to plagiarists. The post Dr. Toth linked closely mirrored what I
initially anticipated from observing kspp and the like from afar. I
think they're in a crap situation and what they've done is one of the
better of several bad options.


So, I am considering the costs of alternative control environments for
my personal systems, perhaps it will be worth the quoted price after all
once I've assessed options.

But, point being, if paying is not out of the question I think you
should request a quote. 


--
0x7D964D3361142ACF

Re: [gentoo-hardened] Technical repercussions of grsecurity removal

[Luis Ressel]

[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-hardened] Technical repercussions of grsecurity removal

[Daniel Cegiełka]

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: [gentoo-hardened] Technical repercussions of grsecurity removal

[Luis Ressel]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-hardened] Technical repercussions of grsecurity removal

[Daniel Cegiełka]

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: [gentoo-hardened] Technical repercussions of grsecurity removal

["Tóth Attila"]

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: [gentoo-hardened] Technical repercussions of grsecurity removal

[Daniel Cegiełka]

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: [gentoo-hardened] Technical repercussions of grsecurity removal

[Alex Efros]

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.