X-Original-To: alpine-devel@lists.alpinelinux.org Received: from burlywood.maple.relay.mailchannels.net (burlywood.maple.relay.mailchannels.net [23.83.214.26]) by lists.alpinelinux.org (Postfix) with ESMTP id 9AEC35C473B for ; Wed, 5 Apr 2017 22:06:24 +0000 (GMT) X-Sender-Id: mxroute|x-authuser|developer@it-offshore.co.uk Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 25080102C83 for ; Wed, 5 Apr 2017 22:06:24 +0000 (UTC) Received: from ocean.mxroute.com (unknown [100.96.126.101]) by relay.mailchannels.net (Postfix) with ESMTPA id BC1C4102C9C for ; Wed, 5 Apr 2017 22:06:23 +0000 (UTC) X-Sender-Id: mxroute|x-authuser|developer@it-offshore.co.uk Received: from ocean.mxroute.com (ocean-ptr.mxroute.com [172.20.108.37]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.7.37); Wed, 05 Apr 2017 22:06:24 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: mxroute|x-authuser|developer@it-offshore.co.uk X-MailChannels-Auth-Id: mxroute X-Wiry-Tasty: 38e7802e3400e5a4_1491429983974_1742583963 X-MC-Loop-Signature: 1491429983974:2450968923 X-MC-Ingress-Time: 1491429983974 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=it-offshore.co.uk; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:To:References:Subject:Reply-To:Sender:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Njbt1d3fex450T+zEQO7xOfynwoQo8pf6tknI2Z2s6g=; b=ADnB+ma5/gPRpzRUG4XSkIxJ4 twW9sc7T7qpx8oZa90kiwk+sxGPawuA35wEsQACE0+rqFdfcWJCL07GRYZdXjx6bax7vo6DTdoKvw caVJxx+NOQnUd1H9gBaDjlH7KLUcSmJRziDgF0h8YcYNveyrHfD/kDmAsBgeTwkq/DMpUEbSk8/mg YbwRxY2cUuugu5C1Pw5nMHDWLqTy6DO3ueDpEUljHAYZS5ipA4Axnm0f9/CIohxMekF5MmBaVB2kk RXbySrcU+OrViPByZiNhk06pfKSITQYTczQTbh+VXKpO8sM9vAEo2Q0v5hxrv2luYr70VDXi/Aua3 7cDy3peTA==; Reply-To: developer@it-offshore.co.uk Subject: Re: [alpine-devel] grsec go or no-go call for 3.6 References: <6cb1b9fe292e94575683ea97bafe2c61@alpinelinux.org> <20170405220743.0fb80170@ncopa-desktop.copa.dup.pw> To: alpine-devel@lists.alpinelinux.org From: Stuart Cardall Message-ID: Date: Wed, 5 Apr 2017 23:06:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 In-Reply-To: <20170405220743.0fb80170@ncopa-desktop.copa.dup.pw> Content-Type: multipart/alternative; boundary="------------7FFEC352390DA4AA88248C84" X-OutGoing-Spam-Status: No, score=-7.4 X-AuthUser: developer@it-offshore.co.uk This is a multi-part message in MIME format. --------------7FFEC352390DA4AA88248C84 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit If possible it would be good to keep grsecurity. It mitigates attacks on php-fpm: "bruteforce prevention initiated for the next 30 minutes or until service restarted, stalling each fork 30 seconds." Stuart. On 04/05/2017 09:07 PM, Natanael Copa wrote: > On Sun, 2 Apr 2017 21:18:16 -0500 > William Pitcock wrote: > >> Hello, >> >> On Sun, Apr 2, 2017 at 2:54 PM, Francesco Colista >> wrote: >>> Il 2017-04-02 00:39 William Pitcock ha scritto: >>>> Hello, >>>> >>>> It is getting to the point to decide whether we wish to continue >>>> including grsec kernel for 3.6. >>>> There are three options that I can see: >>>> >>>> 1. Ship grsec in Alpine 3.6 and see what happens. Revisit this issue >>>> in Alpine 3.7. >>> >>> One of the paradigm of Alpine is "secure". >>> grsec contributed so far in making Alpine "secure". >> How has grsec improved the security of aarch64, ppc64le or s390x? >> It has been previously proposed to remove grsec at the same time that >> we remove support for 32-bit x86, should that ever happen. >> >>> I would not make any important decision based on a "possibility", rahter on >>> official announcements. >> Unfortunately, we do need to make a decision. > I think we try keep grsecurity for v3.6. > >> While it is true that upstream may ultimately decide to not withdraw >> the testing patches, it can very easily go the other way. >> Upstream's rationale for withdrawing the testing patches have to do >> with the KSPP project (which is basically incrementally reimplementing >> grsec in mainline), which has the possibility of negatively impacting >> revenue. > And KSPP is like a decade behind, they will have to negotiate the > features (vs speed for example) with the other developers, so they will > never reach the level of protection that Grsecurity provides. > >> Of course, upstream is still invited to comment on whether or not he >> ultimately plans to withdraw the patches or not. > It may be that they will provide the testing patches every 2 years, (or > maybe even for every new LTS kernel). I hope they will realize that > killing the "community" and ecosystem around grsecurity will hurt their > customers and will give at least partial support for a non-official > port of grsecurity. > >> William >> >> >> --- >> Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org >> Help: alpine-devel+help@lists.alpinelinux.org >> --- >> > > > --- > Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org > Help: alpine-devel+help@lists.alpinelinux.org > --- > --------------7FFEC352390DA4AA88248C84 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

If possible it would be good to keep grsecurity. It mitigates attacks on php-fpm:

"bruteforce prevention initiated for the next 30 minutes or until service restarted, stalling each fork 30 seconds."

Stuart.


On 04/05/2017 09:07 PM, Natanael Copa wrote:
On Sun, 2 Apr 2017 21:18:16 -0500
William Pitcock <nenolod@dereferenced.org> wrote:


Hello,

On Sun, Apr 2, 2017 at 2:54 PM, Francesco  Colista
<fcolista@alpinelinux.org> wrote:

Il 2017-04-02 00:39 William Pitcock ha scritto:  

Hello,

It is getting to the point to decide whether we wish to continue
including grsec kernel for 3.6.
There are three options that I can see:

1. Ship grsec in Alpine 3.6 and see what happens.  Revisit this issue
in Alpine 3.7.  


One of the paradigm of Alpine is "secure".
grsec contributed so far in making Alpine "secure".  

How has grsec improved the security of aarch64, ppc64le or s390x?
It has been previously proposed to remove grsec at the same time that
we remove support for 32-bit x86, should that ever happen.


I would not make any important decision based on a "possibility", rahter on
official announcements.  

Unfortunately, we do need to make a decision.

I think we try keep grsecurity for v3.6.


While it is true that upstream may ultimately decide to not withdraw
the testing patches, it can very easily go the other way.
Upstream's rationale for withdrawing the testing patches have to do
with the KSPP project (which is basically incrementally reimplementing
grsec in mainline), which has the possibility of negatively impacting
revenue.

And KSPP is like a decade behind, they will have to negotiate the
features (vs speed for example) with the other developers, so they will
never reach the level of protection that Grsecurity provides.


Of course, upstream is still invited to comment on whether or not he
ultimately plans to withdraw the patches or not.

It may be that they will provide the testing patches every 2 years, (or
maybe even for every new LTS kernel). I hope they will realize that
killing the "community" and ecosystem around grsecurity will hurt their
customers and will give at least partial support for a non-official
port of grsecurity.


William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---




---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

--------------7FFEC352390DA4AA88248C84-- --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---