From nobody Thu Mar 28 12:07:53 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com [209.85.220.177]) by lists.alpinelinux.org (Postfix) with ESMTP id 4B2825C468C for ; Mon, 3 Apr 2017 02:18:17 +0000 (GMT) Received: by mail-qk0-f177.google.com with SMTP id p22so103529033qka.3 for ; Sun, 02 Apr 2017 19:18:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dereferenced-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1gbkcwz7aYIcJqAdp58hoCeV4qut/Gj5XT48/n2FEKM=; b=1ouy7trxlki/HqXXN1HjQc0xC9yDw28XS5OSu19gQjXKbJmFdqOYZTBMuFW9GgWvx4 Y/+PTIpeVHWYcMXshzpgJ5pl1ja7kee+1So5xnfzqfeTh7YQA96gFZxFCvWtG1cZGE4U 3qThnqu/iUVXN96XkpQI/kUpqeCYB/2bvwsgoJZhdBxzWte4+g9YseyO0ipqeGUXqY/q YsOrqFIkMqJc6qCVAb3IKv6yEDBs3tJIp695Aw+D5ZERgIa+11qTOqjP/QqrkR76heLZ HNdGnnf7Lw0R4hw7R6SrppEKvoHNOb003sWvPLduyjmgSv5hLLCMxLiB9UK6M0glX467 m/og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1gbkcwz7aYIcJqAdp58hoCeV4qut/Gj5XT48/n2FEKM=; b=FYQTuaOmg0BCqilwGNcpqzHk4qBLFbJn9XV1MO1fVdmC4yWw3FXhOgozfOqOnQ/6Ze HhVJpckvOPzWm0XoG4YFOGOEHLAYrp79X68lPA2LJtk8MNm5JZcemZ6VkCJrjuFVZ9W5 EYo+o8kIVw4+kLSBNIOpB+LP2y9tp9ZHRc4q4YJgc45k0AAwgoEtxXcddbPRMznUWPP8 ACLifHAy9nPhULg5OdinanHOgZy7LA1ePlnfypy072mb0UdrCD3NX6z/KEPXZm0m+dMj KBWI1KVK9rQLfvd0UekSfzw0HB17EyAE+nVUUQEzUuxCBMy37CrbUNzFZUS99ai06CDg 0jvg== X-Gm-Message-State: AFeK/H107Zxv/4drdXksTDwo9IvIGZO9w0P8dyae0LfyZLY7MFGrKZPb7h0Vr4bSuBaJASPovmN12RAFdk6v6g== X-Received: by 10.55.203.67 with SMTP id d64mr1440484qkj.72.1491185896482; Sun, 02 Apr 2017 19:18:16 -0700 (PDT) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Received: by 10.200.50.49 with HTTP; Sun, 2 Apr 2017 19:18:16 -0700 (PDT) In-Reply-To: <6cb1b9fe292e94575683ea97bafe2c61@alpinelinux.org> References: <6cb1b9fe292e94575683ea97bafe2c61@alpinelinux.org> From: William Pitcock Date: Sun, 2 Apr 2017 21:18:16 -0500 Message-ID: Subject: Re: [alpine-devel] grsec go or no-go call for 3.6 To: Francesco Colista Cc: alpine-dev Content-Type: text/plain; charset=UTF-8 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. 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. Of course, upstream is still invited to comment on whether or not he ultimately plans to withdraw the patches or not. William --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Thu Mar 28 12:07:53 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from newmail.tetrasec.net (unknown [172.21.74.12]) by lists.alpinelinux.org (Postfix) with ESMTP id E1E675C472E; Wed, 5 Apr 2017 20:07:47 +0000 (GMT) Received: from ncopa-desktop.copa.dup.pw (15.63.200.37.customer.cdi.no [37.200.63.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: n@tanael.org) by newmail.tetrasec.net (Postfix) with ESMTPSA id 36C915A07B7; Wed, 5 Apr 2017 20:07:47 +0000 (GMT) Date: Wed, 5 Apr 2017 22:07:43 +0200 From: Natanael Copa To: William Pitcock Cc: Francesco Colista , alpine-dev Subject: Re: [alpine-devel] grsec go or no-go call for 3.6 Message-ID: <20170405220743.0fb80170@ncopa-desktop.copa.dup.pw> In-Reply-To: References: <6cb1b9fe292e94575683ea97bafe2c61@alpinelinux.org> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.28; x86_64-alpine-linux-musl) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 --- From nobody Thu Mar 28 12:07:53 2024 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 ---