All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Mathias Krause <minipli@googlemail.com>
Cc: "Kees Cook" <keescook@chromium.org>,
	"Daniel Cegiełka" <daniel.cegielka@gmail.com>,
	"kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>
Subject: Re: [kernel-hardening] It looks like there will be no more public versions of PaX and Grsec.
Date: Wed, 03 May 2017 15:02:28 -0400	[thread overview]
Message-ID: <1493838148.20270.12.camel@redhat.com> (raw)
In-Reply-To: <CA+rthh_JNuXHmVBE8vz-CxQZwJsW=NR8DUfGq5aMHj42VFkpog@mail.gmail.com>

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

On Tue, 2017-05-02 at 23:16 +0200, Mathias Krause wrote:
> On 2 May 2017 at 02:09, Rik van Riel <riel@redhat.com> wrote:
> > On Tue, 2017-05-02 at 00:01 +0200, Mathias Krause wrote:
> > 
> > > I think the intention of the KSPP is good -- making vanilla Linux
> > > more
> > > secure. But the way it does its work harms overall Linux
> > > security. It
> > > does hurt mine, that's for sure!
> > 
> > Yeah, no.
> 
> Well, yes, it does! Losing access to the grsecurity patch makes the
> systems I do care about much less secure.

Your systems are not necessarily representative of the
overall security of all Linux systems in the world,
though.

> > The grsecurity people produced patches
> > that were used on maybe a few tens of thousands
> > of systems,
> 
> Where did you pull that number from? Out of thin air, I guess. I
> know,
> for sure, there are many more installations.

I have seen a few emails suggesting there are millions
of systems with grsecurity patches around, and I got
the number wrong by several orders of magnitude.

However, that does not invalidate my original point:
the number of grsecurity protected systems is only a tiny
fraction of the entire Linux installed base.

It would be good to get hardening functionality upstream,
in order to get a majority of Linux systems (that get
deployed in the future) hardened out of the box.

> > Those Android devices are more likely to require
> > hardening, too, since they do not receive security
> > updates as quickly as the systems maintained by
> > grsecurity users.
> 
> Why couldn't those devices benefit from grsecurity as well? Couldn't
> google or Samsung just integrate grsecurity into their Android
> kernels? They're far away from vanilla Linux anyway, so why not add
> just another patch to provide some matured security code base to
> protect those billion of Android devices? I'd guess, if a big player
> like google would sponsor / pay grsecurity to provide a patch for the
> relevant Android kernels, all sides would be happy: grsecurity for
> getting wider adoption, Android users for having secured systems.

They could, but the reality is many vendors will not
bother enabling hardening features unless the code is
already there and enabled by default in the upstream
kernel.

> > Integrating hardening into the upstream kernel is
> > a good thing for security, not a bad thing.
> 
> I never said it's a bad thing. Indeed I'm all for making vanilla
> Linux
> more secure. Just how KSPP tries to do it is IMHO wrong. Ripping
> hunks
> out of grsecurity and trying to integrate them into vanilla Linux
> without understanding all the interdependencies or even the features
> themselves, how would that provide security? By chance, maybe. But
> not
> intentional, as that requires having thought of every corner case and
> boundary condition.

How would you do it?

Maintainers integrate code one patch series at a
time. That is not a constraint you can work around,
because code does need to be reviewed.

-- 
All rights reversed

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  parent reply	other threads:[~2017-05-03 19:02 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-26 21:05 [kernel-hardening] It looks like there will be no more public versions of PaX and Grsec Daniel Cegiełka
2017-04-26 22:04 ` Kees Cook
2017-05-01 22:01   ` Mathias Krause
2017-05-02  0:09     ` Rik van Riel
2017-05-02 14:46       ` Shawn
2017-05-02 18:55         ` Kees Cook
2017-05-03  4:50           ` Shawn
2017-05-03 18:56             ` Rik van Riel
2017-05-03 19:36               ` Daniel Micay
2017-05-04  5:45             ` Kees Cook
2017-05-04  6:47               ` Lionel Debroux
2017-05-05 19:54                 ` Kees Cook
2017-05-04 14:11               ` Shawn
2017-05-04 16:03                 ` Greg KH
2017-05-04 17:12                   ` Shawn
2017-05-04 17:23                     ` Greg KH
2017-05-02 21:16       ` Mathias Krause
2017-05-02 21:50         ` Casey Schaufler
2017-05-02 22:57         ` Kees Cook
2017-05-03 19:02         ` Rik van Riel [this message]
2017-05-03 19:27           ` Daniel Micay
2017-05-02  0:39     ` Olof Johansson
2017-05-02  0:44     ` Casey Schaufler
2017-05-02  0:54     ` Kees Cook
2017-05-11  1:24       ` PaX Team
2017-05-11 16:30         ` Daniel Micay
2017-05-11 18:02         ` Kees Cook
2017-05-12 11:34           ` Hunger
2017-07-31 13:38         ` Solar Designer
2017-05-02 11:11     ` David Gens
2017-05-02 21:27       ` Mathias Krause
2017-05-03  8:59         ` David Gens
2017-05-03 19:10           ` Rik van Riel
     [not found] <1788778362.1495506.1493751985632.ref@mail.yahoo.com>
2017-05-02 19:06 ` Lionel Debroux
2017-05-02 22:35   ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1493838148.20270.12.camel@redhat.com \
    --to=riel@redhat.com \
    --cc=daniel.cegielka@gmail.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=minipli@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.