Mailing List Archive

Hi!

On Sat, Apr 29, 2017 at 01:49:20PM +0200, Luis Ressel wrote:
> I suppose we all just grudgingly switch over to gentoo-sources?

I wonder for how long time current kernel with grsec will be more safe and
protected against new exploits than up-to-date gentoo-sources…
Something new in security: avoid updates to have better protection.

--
WBR, Alex.

Hi!

On Sat, Apr 29, 2017 at 01:49:20PM +0200, Luis Ressel wrote:
> in case anyone hasn't read in on LWN yet, here's what I'm talking
> about: https://grsecurity.net/passing_the_baton.php

Sorry for OT, but is this legal? Or, more correct, is this will works?

Sure, they can sell their patch to Linux kernel without opensourcing that
patch. But at soon as their customers (say, some government org or large
company) will APPLY that patch to Linux kernel and try to DISTRIBUTE that
kernel on their computers - they will have to distribute patched source
too (so it'll became available to users of these computers), and that
patched source will have GPL2 license… so any of these users/employees may
publish these sources, and org/company can't prohibit this without
violating GPL2… correct?

Or this will be sort of "sure, you may publish these sources, but then we
may fire you - everyone has rights, right to publish any GPL2 sources he
has access to and right to fire any employee for no specific reason"?

--
WBR, Alex.

On 29 Apr 2017 at 16:11, Alex Efros wrote:

> Hi!
>
> On Sat, Apr 29, 2017 at 01:49:20PM +0200, Luis Ressel wrote:
> > in case anyone hasn't read in on LWN yet, here's what I'm talking
> > about: https://grsecurity.net/passing_the_baton.php
>
> Sorry for OT, but is this legal? Or, more correct, is this will works?
>
> Sure, they can sell their patch to Linux kernel without opensourcing that
> patch.

granted that 'open source' is a rather loaded term these days, i think it
never meant 'available to the public' (shareware would be 'open source' too
then), just that the license is 'open' (whose definition the FSF and others
don't necessarily agree on either). there's plenty of 'open source' licenced
code that never sees the light of day outside of a group of users.

> But at soon as their customers (say, some government org or large
> company) will APPLY that patch to Linux kernel and try to DISTRIBUTE that
> kernel on their computers

there's no need to speculate on this, the FSF has already answered it:
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#InternalDistribution

On 29/04/2017 15:11, Alex Efros wrote:
> Sure, they can sell their patch to Linux kernel without opensourcing that
> patch. But at soon as their customers (say, some government org or large
> company) will APPLY that patch to Linux kernel and try to DISTRIBUTE that
> kernel on their computers - they will have to distribute patched source
> too (so it'll became available to users of these computers), and that
> patched source will have GPL2 license… so any of these users/employees may
> publish these sources, and org/company can't prohibit this without
> violating GPL2… correct?

See the discussion on https://lwn.net/Articles/720983/ .

Pawe?

2017-04-29 14:47 GMT+02:00 Alex Efros <powerman@powerman.name>:
> Hi!
>
> On Sat, Apr 29, 2017 at 01:49:20PM +0200, Luis Ressel wrote:
>> I suppose we all just grudgingly switch over to gentoo-sources?
>
> I wonder for how long time current kernel with grsec will be more safe and
> protected against new exploits than up-to-date gentoo-sources…
> Something new in security: avoid updates to have better protection.

It's not about grsecurity, it's about PaX. This was the basic layer
of protection. Gentoo Hardened has spent years working to provide PaX
support in userland. It was the core of this project. Alpine Linux and
others are also based on PaX. After years of building _trust_, it all
disappears overnight. You can use Grsecurity, you can use SELinux, you
can use RSBAC, but you do not have a good alternative for PaX. And
this is an existential problem for all these projects. By the way, I
don't know what the Gentoo Hardened or Alpine Linux have done wrong,
that now are left out in the cold.

Instead of complaining, we have to decide what to do next. In my
opinion, it is critical to maintain support for PaX* for future
kernels. It will not be easy, so I'm right away saying that Gentoo
Hardened, Alpine Linux etc. should join forces in realizing this
project. I think there will be more people who will be interested
in...

* https://www.grsecurity.net/~paxguy1/

Daniel

Hi!

On Sat, Apr 29, 2017 at 03:46:54PM +0200, PaX Team wrote:
> > But at soon as their customers (say, some government org or large
> > company) will APPLY that patch to Linux kernel and try to DISTRIBUTE that
> > kernel on their computers
>
> there's no need to speculate on this, the FSF has already answered it:
> https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.en.html#InternalDistribution

Thanks! But isn't this mean you forbid all Linux distributions (including
commercial ones like RedHat) to be GrSec/PaX subscribers (in case they
like to spend some money for it)? I.e. this decision will ensure majority
of Linux systems will never ever have GrSec/PaX (yeah, in theory some
RedHat user may subscribe and manually recompile own kernel, but we all
knows this never happens - at large at least, but very likely at all)?

--
WBR, Alex.

It's not one PaX alternative as its only one of its features but rsbac
recently implemented native W or X and seems to work fine


On 29/04/17 17:56, Daniel Cegie?ka wrote:
> 2017-04-29 14:47 GMT+02:00 Alex Efros <powerman@powerman.name>:

> It's not about grsecurity, it's about PaX. This was the basic layer
> of protection. Gentoo Hardened has spent years working to provide PaX
> support in userland. It was the core of this project. Alpine Linux and
> others are also based on PaX. After years of building _trust_, it all
> disappears overnight. You can use Grsecurity, you can use SELinux, you
> can use RSBAC, but you do not have a good alternative for PaX. And
> this is an existential problem for all these projects. By the way, I
> don't know what the Gentoo Hardened or Alpine Linux have done wrong,
> that now are left out in the cold.
>
> Instead of complaining, we have to decide what to do next. In my
> opinion, it is critical to maintain support for PaX* for future
> kernels. It will not be easy, so I'm right away saying that Gentoo
> Hardened, Alpine Linux etc. should join forces in realizing this
> project. I think there will be more people who will be interested
> in...
>
> * https://www.grsecurity.net/~paxguy1/
>
> Daniel
>

On Sat, 29 Apr 2017 18:52:56 +0200
Javier Juan Martinez Cabezon <tazok.id0@gmail.com> wrote:

> It's not one PaX alternative as its only one of its features but rsbac
> recently implemented native W or X and seems to work fine

If you're only looking for userland W^X, SELinux has some support for
that, too (I don't know anything about the internal workings, though).
But grsec/PaX has quite some interesting features beyond that.

Regards,
Luis

On Sat, 29 Apr 2017 17:56:10 +0200
Daniel Cegie?ka <daniel.cegielka@gmail.com> wrote:

> By the way, I don't know what the Gentoo Hardened or Alpine Linux
> have done wrong, that now are left out in the cold.

That's the part I don't get either. Since the only possible motivation
I can think of for this move is to generate more income, they could've
at least tried asking the community for donations first.

Now, I suppose someone is going to answer "If you'd be willing do
regularily donate to them, you might as well get a subscription", but I
fear this might have some serious drawbacks. In the past years,
the Gentoo Hardened devs have invested quite some work to make sure
most applications in the tree work on grsec/PaX-enabled kernels without
too much fallout. But now, there's suddently a lot less motivation to
keep up this work.

> Instead of complaining, we have to decide what to do next. In my
> opinion, it is critical to maintain support for PaX* for future
> kernels. It will not be easy, so I'm right away saying that Gentoo
> Hardened, Alpine Linux etc. should join forces in realizing this
> project. I think there will be more people who will be interested
> in...

It might be hard to come up with the manpower needed to maintain such a
large kernel patch. Assuming upstream stand by their decision in
the long run, I think the only reasonable long-term approach would be to
try mainlining as much as possible and forget about the rest. And as
Brad and PaX Team can surely tell us, that'd be a gargantuan task if it
is at all possible.

Regards,
Luis

2017-04-29 19:04 GMT+02:00 Luis Ressel <aranea@aixah.de>:
> On Sat, 29 Apr 2017 17:56:10 +0200
> Daniel Cegie?ka <daniel.cegielka@gmail.com> wrote:
>
>> By the way, I don't know what the Gentoo Hardened or Alpine Linux
>> have done wrong, that now are left out in the cold.
>
> That's the part I don't get either. Since the only possible motivation
> I can think of for this move is to generate more income, they could've
> at least tried asking the community for donations first.

It's more complex:

https://www.theregister.co.uk/2015/08/27/grsecurity/

I don't judge them. I'm interested in the future of projects that were
heavily dependent on PaX (Gentoo Hardened, Alpine Linux).

> Now, I suppose someone is going to answer "If you'd be willing do
> regularily donate to them, you might as well get a subscription", but I
> fear this might have some serious drawbacks. In the past years,
> the Gentoo Hardened devs have invested quite some work to make sure
> most applications in the tree work on grsec/PaX-enabled kernels without
> too much fallout. But now, there's suddently a lot less motivation to
> keep up this work.

Ned Lud (or Solar, but != Designer) has put a lot of work into the
launch of Gentoo Hardened and, of course, the popularization of PaX.
Old times.. :)


>> Instead of complaining, we have to decide what to do next. In my
>> opinion, it is critical to maintain support for PaX* for future
>> kernels. It will not be easy, so I'm right away saying that Gentoo
>> Hardened, Alpine Linux etc. should join forces in realizing this
>> project. I think there will be more people who will be interested
>> in...
>
> It might be hard to come up with the manpower needed to maintain such a
> large kernel patch. Assuming upstream stand by their decision in
> the long run, I think the only reasonable long-term approach would be to
> try mainlining as much as possible and forget about the rest. And as
> Brad and PaX Team can surely tell us, that'd be a gargantuan task if it
> is at all possible.

Patch weight is not the problem.. KSPP is. They copy (raw copy.. I
hope) code from PaX and bring it to the kernel:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c054ee3bbf69ebcabb1f3218b7faf4b1b37a8eb6

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f5509cc18daa7f82bcc553be70df2117c8eedc16

This means that there will be conflicts in the future. I don't claim
that maintaining PaX support will be easy, but it's possible to do so.

Daniel

2017.Április 29.(Szo) 20:43 id?pontban Daniel Cegie?ka ezt írta:
>> That's the part I don't get either. Since the only possible motivation
>> I can think of for this move is to generate more income, they could've
>> at least tried asking the community for donations first.
>
> It's more complex:
>
> https://www.theregister.co.uk/2015/08/27/grsecurity/
>
> I don't judge them. I'm interested in the future of projects that were
> heavily dependent on PaX (Gentoo Hardened, Alpine Linux).

I also have concernes about the future of Gentoo Hardened userspace.
Security initiatives drew my attention 15+ years ago, when Adamantix was
alive. After discontinuation of the project I've discovered Gentoo
Hardened as something providing a remedy for security-aware refugees. Over
the years I get used to the infrastructure of Daniel Robbins' Gentoo and
experienced the benefits of the rolling release nature of the distro and
all those simple compile time tools provides to the power users.
When you go hardened, you cant stop it.
I wish Hardened Gentoo survives and continue to exist for long.

>> Now, I suppose someone is going to answer "If you'd be willing do
>> regularily donate to them, you might as well get a subscription", but I
>> fear this might have some serious drawbacks. In the past years,
>> the Gentoo Hardened devs have invested quite some work to make sure
>> most applications in the tree work on grsec/PaX-enabled kernels without
>> too much fallout. But now, there's suddently a lot less motivation to
>> keep up this work.

Personal subscription was my first idea. I've made several small donations
for the past decade. However a small fee equivalent to an antivirus
software subsription or an Android app has an effect if there are enough
people in the community. My guess is a project like grsecurity won't
really depend on some individual users. Individuals of the community are
suffering collateral damage currently.

> Ned Lud (or Solar, but != Designer) has put a lot of work into the
> launch of Gentoo Hardened and, of course, the popularization of PaX.
> Old times.. :)

Yes, Ned Ludd.

> This means that there will be conflicts in the future. I don't claim
> that maintaining PaX support will be easy, but it's possible to do so.

I believe the community and grsecurity will find a solution soon. Hardened
Gentoo provided a basis for test patches.
I understand the developers of grsecurity getting fed up by legal issues
and having a lack of time dealing with problems they don't want to spend
their resources on. I hope there will be a good solution for every
benevolent parties involved.

Dwokfur

Thanks to everyone involved in the Gentoo Hardened project, especially
Spender and Pax Guy, for the effort and guidance throughout the years. The
anecdotes shared in this thread echo my own experiences to a degree, and
I've learned a lot about computer security by trying to get the grsec RBAC
system fully functional.

It's saddening to read the news today, and also to read that article in The
Guardian; makes me really wish I'd been much more involved with this stuff.

I donated a small amount, long ago, and always felt a sense of pride seeing
my name on the grsec website.

Here's to (not) getting rewted!

On Apr 29, 2017 4:34 PM, Tóth Attila <atoth@atoth.sote.hu> wrote:

> 2017.Április 29.(Szo) 20:43 id?pontban Daniel Cegie?ka ezt írta:
> >> That's the part I don't get either. Since the only possible motivation
> >> I can think of for this move is to generate more income, they could've
> >> at least tried asking the community for donations first.
> >
> > It's more complex:
> >
> > https://www.theregister.co.uk/2015/08/27/grsecurity/
> >
> > I don't judge them. I'm interested in the future of projects that were
> > heavily dependent on PaX (Gentoo Hardened, Alpine Linux).
>
> I also have concernes about the future of Gentoo Hardened userspace.
> Security initiatives drew my attention 15+ years ago, when Adamantix was
> alive. After discontinuation of the project I've discovered Gentoo
> Hardened as something providing a remedy for security-aware refugees. Over
> the years I get used to the infrastructure of Daniel Robbins' Gentoo and
> experienced the benefits of the rolling release nature of the distro and
> all those simple compile time tools provides to the power users.
> When you go hardened, you cant stop it.
> I wish Hardened Gentoo survives and continue to exist for long.
>
> >> Now, I suppose someone is going to answer "If you'd be willing do
> >> regularily donate to them, you might as well get a subscription", but I
> >> fear this might have some serious drawbacks. In the past years,
> >> the Gentoo Hardened devs have invested quite some work to make sure
> >> most applications in the tree work on grsec/PaX-enabled kernels without
> >> too much fallout. But now, there's suddently a lot less motivation to
> >> keep up this work.
>
> Personal subscription was my first idea. I've made several small donations
> for the past decade. However a small fee equivalent to an antivirus
> software subsription or an Android app has an effect if there are enough
> people in the community. My guess is a project like grsecurity won't
> really depend on some individual users. Individuals of the community are
> suffering collateral damage currently.
>
> > Ned Lud (or Solar, but != Designer) has put a lot of work into the
> > launch of Gentoo Hardened and, of course, the popularization of PaX.
> > Old times.. :)
>
> Yes, Ned Ludd.
>
> > This means that there will be conflicts in the future. I don't claim
> > that maintaining PaX support will be easy, but it's possible to do so.
>
> I believe the community and grsecurity will find a solution soon. Hardened
> Gentoo provided a basis for test patches.
> I understand the developers of grsecurity getting fed up by legal issues
> and having a lack of time dealing with problems they don't want to spend
> their resources on. I hope there will be a good solution for every
> benevolent parties involved.
>
> Dwokfur
>
>
>

On 29/04/17 18:58, Luis Ressel wrote:
> On Sat, 29 Apr 2017 18:52:56 +0200
> Javier Juan Martinez Cabezon <tazok.id0@gmail.com> wrote:
>
>> It's not one PaX alternative as its only one of its features but rsbac
>> recently implemented native W or X and seems to work fine
>
> If you're only looking for userland W^X, SELinux has some support for
> that, too (I don't know anything about the internal workings, though).
> But grsec/PaX has quite some interesting features beyond that.
>
> Regards,
> Luis
>


I think that if Pipacs want to follow his own way, it's his decision and
we shall respect it.

W or X its implemented in selinux and rsbac, nx gets shipped in recent
systems, but in those computers that haven't nx it couldn't get emulated
without PaX, there are some gcc plugins that emulates some kernel land
PaX features as uderef, vanilla brings some ASLR, maybe not perfect o
weakier buy maybe hardened gentoo could follow this path and could be
coherent with their own way of working, with profiles and specs.

Hi!

On Sat, Apr 29, 2017 at 07:46:10PM +0300, Alex Efros wrote:
> Thanks! But isn't this mean you forbid all Linux distributions (including
> commercial ones like RedHat) to be GrSec/PaX subscribers (in case they
> like to spend some money for it)? I.e. this decision will ensure majority
> of Linux systems will never ever have GrSec/PaX

If no one is replies on this yet because that's sad truth, then may I ask
why don't you like to solve this in some way?

For example, you can continue publishing source of GrSec/PaX versions, but
use license which allows using it for free only for personal use and small
business (say, less than 10-20 computers) on usual desktop/server PC.
This way all server/desktop Linux distributions will be able to include
alternative hardened kernel or have alternative hardened variant of
overall distribution, but end-user will have to decide is they can use it
for free or should subscribe or avoid using it.
For Android phones/tablets and embedded devices you can make separate
clause in license to let you get some money from Google and companies
developing embedded devices if they will like to use GrSec/PaX, without
forbidding such a possibility at all (rumours are current subscription
options require to limit amount of installations, which is surely doesn't
makes sense for Android).

This way you shouldn't lose any money comparing to current situation,
it also solve mentioned before issues when bad companies sell unsupported
and modified GrSec variant and use "grsecurity" for marketing own
products. Plus you'll continue wide-test your patch with Gentoo Hardened
and some other distribution users and have your patch available for any
external audit which is always good for security product's karma.

If there are no good reasons to reject proposed solution and no
alternatives to let people continue using GrSec/PaX for personal/small
business use, then, yeah, conspiracy theories and three-letter-agencies
start coming to mind - just because they wins more than anybody else
including yourself if all Linux distributions won't have GrSec/PaX anymore.

--
WBR, Alex.

You can't really change license because it is a kernel patch so it has
to be GPLv2 from what i understand.


On 04/30/2017 01:08 PM, Alex Efros wrote:
> Hi!
>
> On Sat, Apr 29, 2017 at 07:46:10PM +0300, Alex Efros wrote:
>> Thanks! But isn't this mean you forbid all Linux distributions (including
>> commercial ones like RedHat) to be GrSec/PaX subscribers (in case they
>> like to spend some money for it)? I.e. this decision will ensure majority
>> of Linux systems will never ever have GrSec/PaX
> If no one is replies on this yet because that's sad truth, then may I ask
> why don't you like to solve this in some way?
>
> For example, you can continue publishing source of GrSec/PaX versions, but
> use license which allows using it for free only for personal use and small
> business (say, less than 10-20 computers) on usual desktop/server PC.
> This way all server/desktop Linux distributions will be able to include
> alternative hardened kernel or have alternative hardened variant of
> overall distribution, but end-user will have to decide is they can use it
> for free or should subscribe or avoid using it.
> For Android phones/tablets and embedded devices you can make separate
> clause in license to let you get some money from Google and companies
> developing embedded devices if they will like to use GrSec/PaX, without
> forbidding such a possibility at all (rumours are current subscription
> options require to limit amount of installations, which is surely doesn't
> makes sense for Android).
>
> This way you shouldn't lose any money comparing to current situation,
> it also solve mentioned before issues when bad companies sell unsupported
> and modified GrSec variant and use "grsecurity" for marketing own
> products. Plus you'll continue wide-test your patch with Gentoo Hardened
> and some other distribution users and have your patch available for any
> external audit which is always good for security product's karma.
>
> If there are no good reasons to reject proposed solution and no
> alternatives to let people continue using GrSec/PaX for personal/small
> business use, then, yeah, conspiracy theories and three-letter-agencies
> start coming to mind - just because they wins more than anybody else
> including yourself if all Linux distributions won't have GrSec/PaX anymore.
>

And it's not about money from what I've read, should read this if you
want some more information :
https://hardenedlinux.github.io/announcement/2017/04/29/hardenedlinux-statement2.html

On 04/30/2017 01:50 PM, SK wrote:
> You can't really change license because it is a kernel patch so it has
> to be GPLv2 from what i understand.
>
>
> On 04/30/2017 01:08 PM, Alex Efros wrote:
>> Hi!
>>
>> On Sat, Apr 29, 2017 at 07:46:10PM +0300, Alex Efros wrote:
>>> Thanks! But isn't this mean you forbid all Linux distributions (including
>>> commercial ones like RedHat) to be GrSec/PaX subscribers (in case they
>>> like to spend some money for it)? I.e. this decision will ensure majority
>>> of Linux systems will never ever have GrSec/PaX
>> If no one is replies on this yet because that's sad truth, then may I ask
>> why don't you like to solve this in some way?
>>
>> For example, you can continue publishing source of GrSec/PaX versions, but
>> use license which allows using it for free only for personal use and small
>> business (say, less than 10-20 computers) on usual desktop/server PC.
>> This way all server/desktop Linux distributions will be able to include
>> alternative hardened kernel or have alternative hardened variant of
>> overall distribution, but end-user will have to decide is they can use it
>> for free or should subscribe or avoid using it.
>> For Android phones/tablets and embedded devices you can make separate
>> clause in license to let you get some money from Google and companies
>> developing embedded devices if they will like to use GrSec/PaX, without
>> forbidding such a possibility at all (rumours are current subscription
>> options require to limit amount of installations, which is surely doesn't
>> makes sense for Android).
>>
>> This way you shouldn't lose any money comparing to current situation,
>> it also solve mentioned before issues when bad companies sell unsupported
>> and modified GrSec variant and use "grsecurity" for marketing own
>> products. Plus you'll continue wide-test your patch with Gentoo Hardened
>> and some other distribution users and have your patch available for any
>> external audit which is always good for security product's karma.
>>
>> If there are no good reasons to reject proposed solution and no
>> alternatives to let people continue using GrSec/PaX for personal/small
>> business use, then, yeah, conspiracy theories and three-letter-agencies
>> start coming to mind - just because they wins more than anybody else
>> including yourself if all Linux distributions won't have GrSec/PaX anymore.
>>
>

On Sun, 30 Apr 2017 13:55:16 +0200 SK wrote:
> And it's not about money from what I've read, should read this if you
> want some more information :
> https://hardenedlinux.github.io/announcement/2017/04/29/hardenedlinux-statement2.html

Sounds like a very lame excuse...

> Closing the public access doesn’t make PaX/Grsecurity a
> non-free/libre software. Those who purchase subscriptions can
> access the source code. We don’t see GPL violated in any way here.

The devil is in the detail. If subscribers will not be restricted
in all four freedoms including distribution, than this is
unfortunate, but legal action. But if subscribers will be limited
in distribution of the source code, e.g. by a threat of cancelling
their subscription, this will be illegal, this will be GPLv2
violation and PaXTeam will turn into bunch of criminals.

> After all, it’s PaX team/Spender’s creation and they can do
> anything they want.

No, they can't, because it is not their exclusive creation: many
people have contributed to PaX/GrSec over past years and they also
have rights for parts of these code. Moreover PaXTeam is using Linux
kernel code (without it the whole project is meaningless) and they
must respect copyright right and authorship of everyone who
contibuted to the Linux kernel. If GPLv2 is respected, all is OK.
But PaXTeams plays on the very edge of GPLv2 violation right now
(without the exact terms of the subscription it is not possible to
say if GPLv2 is violated or not).

Frankly, I'm more and more convinced that the real reason behind
all this charade is that GrSec/PaX is indeed a very powerful
security technology. So powerful that in became a serious hindrance
for nsa (or any other shitty agency) and PaXTeam was nailed down to
provide further updates only to "proper" customers and cut off wide
FOSS community from this powerful technology. Of course they likely
have some secret court orders denying them to disclosure the real
reason, so we all are watching this charade.

P.S. Please do not top-post.

Best regards,
Andrew Savchenko

Hi!

On Sun, Apr 30, 2017 at 01:55:16PM +0200, SK wrote:
> And it's not about money from what I've read, should read this if you
> want some more information :

If it's all just about credits, ego and personal conflict with LF - when
they the hell it affects everybody else? AFAIK Gentoo Hardened and
probably most other distributions which use GrSec/PaX have nothing with
all of this. Wanna say "fuuuu" to LF? No prob, change license to say only
listed Linux distributions may continue using GrSec/PaX for free.
This will makes it very clear sign of LF doesn't control GrSec/PaX and
doesn't punish end-users who has nothing with LF and that conflict.


But my original question has nothing with all of this. I was asking how it
possible for security-concerned people like GrSec/PaX developers to make
decisions which will leave vast majority of Linux systems less protected
than they are now? No matter because of that - money, credits, ego… -
none of these worth such a high damage to the world. And is it possible to
somehow minimize that damage. That's it.


P.S. I'm Linux user since 1994. And since that time I hear about LF twice:
read in news when it was created… and yesterday. That's because I'm doing
real work instead of playing politics. One may name it ignorance instead
and tell me if I leave politics alone it doesn't means politics will leave
me alone too… and that's true, of course. But at the end of day there is
no such thing as abstract politics, it's always about concrete people
making concrete decisions. And here we've very concrete GrSec/PaX
developers making very concrete decision to harm overall world security.

P.P.S. Leave NSA alone for the moment, because if it's all NSA then all we
can do is to hope Google or anyone else who has enough resources and good
will will just fork GrSec/PaX and continue developing it under GPL2.
And this discussion then doesn't makes any sense. There is a very small
but still non-zero chance my posts will change GrSec/PaX developers mind
about all of this, but none I can say may affects Google's decision to
fork or not to fork.

Also, if it's NSA case, next step will be to add backdoor into GrSec/PaX
(I suppose everyone realize that) which will eventually ruin Open Source
Security Inc. business anyway. So I just choose to believe this isn't the
case and no matter how strong NSA may push on them they didn't give up.
And all what's happens now has nothing with NSA.

--
WBR, Alex.

On Sat, 29 Apr 2017 22:34:14 +0200 Tóth Attila wrote:
> 2017.Április 29.(Szo) 20:43 id?pontban Daniel Cegie?ka ezt írta:
> >> That's the part I don't get either. Since the only possible motivation
> >> I can think of for this move is to generate more income, they could've
> >> at least tried asking the community for donations first.
> >
> > It's more complex:
> >
> > https://www.theregister.co.uk/2015/08/27/grsecurity/
> >
> > I don't judge them. I'm interested in the future of projects that were
> > heavily dependent on PaX (Gentoo Hardened, Alpine Linux).
>
> I also have concernes about the future of Gentoo Hardened userspace.
> Security initiatives drew my attention 15+ years ago, when Adamantix was
> alive. After discontinuation of the project I've discovered Gentoo
> Hardened as something providing a remedy for security-aware refugees. Over
> the years I get used to the infrastructure of Daniel Robbins' Gentoo and
> experienced the benefits of the rolling release nature of the distro and
> all those simple compile time tools provides to the power users.
> When you go hardened, you cant stop it.
> I wish Hardened Gentoo survives and continue to exist for long.

The only way to preserve this functionality in the long run is to
port it to the mainline kernel. This will not be easy, most likely
not everything will be accepted, some stuff will have to be
reimplemented using another approaches, etc.

But there is no other way. GrSec/PaX team can be trusted no longer.
They ruined all 16 years of good and trustworthy record by what was
done 3 days ago, though the first bells rang 2 years ago when paid
subscription for stable patches was enforced. Even if they will
yield to the community pressure now, they may repeat this betrayal
later and thus can be trusted no longer.

Best regards,
Andrew Savchenko

Hi,

On Sat, 29 Apr 2017 15:47:44 +0300 Alex Efros wrote:
> Hi!
>
> On Sat, Apr 29, 2017 at 01:49:20PM +0200, Luis Ressel wrote:
> > I suppose we all just grudgingly switch over to gentoo-sources?
>
> I wonder for how long time current kernel with grsec will be more safe and
> protected against new exploits than up-to-date gentoo-sources…
> Something new in security: avoid updates to have better protection.

I assume as long as the vanilla kernel 4.9 is supported upstream it
should be relatively easy to backport all updates to the hardened-
sources. 4.9 is the longterm branch, so hardened users should be
safe for a year or so. By that time one should switch to vanilla
kernel (or whatever replacement will be available), because old and
unmaintained software is the root of all evil in security.

Best regards,
Andrew Savchenko

2017-04-30 13:50 GMT+02:00 SK <yandereson@riseup.net>:
> You can't really change license because it is a kernel patch so it has
> to be GPLv2 from what i understand.

Really? Can you remind me when Grsecurity or PaX Team distributed the
Linux kernel? If they did, all code is under GPL-2. But that never
happened (if I'm right). You can't talk about any GPL violation
because it has nothing to do - Linux kernel was not affected by a
patch that never hit it! :) Funny, but true :)

The second: you can't use grsecurity patch (even now!), because
grsecurity is a registered trademark:

"""
Can I continue to use the name grsecurity?

grsecurity® is a registered trademark by Open Source Security Inc. We
will continue to use it in our official work. We ask that any
community-based ports or additions to the last public official
grsecurity patch not use the grsecurity trademark. Replacing the
"grsec" uname addition, removing the grsecurity boot logo from the
patch, and removing "grsec" from associated package names at minimum
will make this easier and avoid confusion. All copyright and license
notices must remain intact as required by the GPL.
"""

https://grsecurity.net/passing_the_baton_faq.php

Alpine Linux changed the name 'grsec' to 'hardened', but that's not
enough: you need to remove all references to 'grsecurity'. What does
it mean? e.g.:

# sysctl -a | grep grsecurity

Exactly! In practice, this means you can't use grsecurity patch (or
use the sed)! :)

Daniel

Hi!

On Sun, Apr 30, 2017 at 04:00:39PM +0300, Andrew Savchenko wrote:
> The only way to preserve this functionality in the long run is to
> port it to the mainline kernel. This will not be easy, most likely
> not everything will be accepted, some stuff will have to be
> reimplemented using another approaches, etc.

We had 16 years to do this with help of GrSec/PaX developers. It wasn't
happened, and it's unlikely happens now unless some huge company decide to
spend a lot of resources for this. Maybe Google will do, in the name of
increasing Android security. And I'm afraid there are no more options now.

> But there is no other way. GrSec/PaX team can be trusted no longer.
> They ruined all 16 years of good and trustworthy record by what was
> done 3 days ago, though the first bells rang 2 years ago when paid
> subscription for stable patches was enforced. Even if they will
> yield to the community pressure now, they may repeat this betrayal
> later and thus can be trusted no longer.

Hey hey hey! Don't be so harsh. No one is perfect, everyone made mistakes,
and credits/money/ego is very usual "good" reason to made mistake.
Not all people is able to admit their mistakes and fix them, but we still
may believe in GrSec/PaX developers. Just give them some time to cool down
and a few good reasons to change their decision. They've pushed the
button, true, but they can also release the button if they will like to.
And tell it was a "training alert". :)

--
WBR, Alex.

Hi,

On Sun, 30 Apr 2017 15:56:02 +0300 Alex Efros wrote:
> Hi!
>
> On Sun, Apr 30, 2017 at 01:55:16PM +0200, SK wrote:
> > And it's not about money from what I've read, should read this if you
> > want some more information :
>
> If it's all just about credits, ego and personal conflict with LF - when
> they the hell it affects everybody else? AFAIK Gentoo Hardened and
> probably most other distributions which use GrSec/PaX have nothing with
> all of this. Wanna say "fuuuu" to LF? No prob, change license to say only
> listed Linux distributions may continue using GrSec/PaX for free.

They can't do this. Because GrSec/PaX is a derivative from Linux
kernel (and some other projects), so they can't change a license to
the kernel changes they made. If they do, this will be a clear
GPLv2 violation and the LF (as well as any other author of a
tiniest piece of the kernel) may sue them for the license violation.

> Also, if it's NSA case, next step will be to add backdoor into GrSec/PaX
> (I suppose everyone realize that) which will eventually ruin Open Source
> Security Inc. business anyway.

Not necessarily. NSA and affiliates also use Linux and are
interested in the enhanced security. So this company may just move
on the payroll.

But I agree with you that further discussion of possible external
enforcement is unproductive, because there is nothing we can do
here.

Best regards,
Andrew Savchenko

On Sun, 30 Apr 2017 16:16:46 +0300 Alex Efros wrote:
> Hi!
>
> On Sun, Apr 30, 2017 at 04:00:39PM +0300, Andrew Savchenko wrote:
> > The only way to preserve this functionality in the long run is to
> > port it to the mainline kernel. This will not be easy, most likely
> > not everything will be accepted, some stuff will have to be
> > reimplemented using another approaches, etc.
>
> We had 16 years to do this with help of GrSec/PaX developers. It wasn't
> happened, and it's unlikely happens now unless some huge company decide to
> spend a lot of resources for this.

There was not enough motivation for this. Why to invest resources
into porting if it works the way it is? Now situation is different,
so we'll see what follows.

BTW a number of features were ported to or reimplemented in the
mainline kernel: ASLR, MAC, auditing, ptrace snooping protection.
Probably many more, I haven't studies this in detail.

Best regards,
Andrew Savchenko