public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Anthony G. Basile" <blueness@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Regarding the State of PaX in the tree
Date: Mon, 16 Apr 2018 08:31:59 -0400	[thread overview]
Message-ID: <2d1d9b97-184b-3636-d920-5d1cbadb624e@gentoo.org> (raw)
In-Reply-To: <20180416111433.7ea80289@pc1>

On 4/16/18 5:14 AM, Hanno Böck wrote:
> Hi,
> 
> I honestly don't see how it would be feasible to maintain a feature
> that the developers maintaining it have access to.

I think you're missing a negation in there.  Point well taken though.


> 
> I get that this whole pax-thing embodies a huge part of Gentoo history
> and it may feel hard for some to let it go. But things are how they are.

I agree, and we'll have it in our history if hardened-sources ever comes
back.  The only machinery we should keep is install-xattrs which grew
out of the integration of xattr PaX markings but is useful beyond just PaX.

> 
> Regarding the fork states: I followed up on minipli's fork, which
> tried to maintain newer patches of grsec for LTS kernels, but that
> essentially stopped after KPTI/meltdown/retpoline. From what I know
> there's no public grsec patch with kpti or any spectre fixes, thus I
> would very much say you're safer these days with an upstream kernel.
> 

Correct.  I would not use the old hardened-sources or minipli's fork on
any production server.

> I think the only realistic way this support can be upheld would be if
> some people who have access to the grsec sources commit to making sure
> that it is maintained.

Upstream has never responded to any email I sent them.  I had a brief
discussion with spender when the decision came down, and he gave me what
I interpreted as an "I'm sorry this is going to adversely affect you but
it has to be this way."

> 
> 
> There's also another question related to this: What's the future for
> Gentoo hardened?
> From what I can tell hardened consists of:
> * the things that try to make it compatible with grsec/pax
>   (more or less obsolete).
> * things that are now in default profiles anyway (aslr, stack
>   protector).
> * things that probably should be in default profiles (relro, now linker
>   flags)
> * -fstack-check, which should eventually be replaced with
>   -fstack-clash-protection (only available in future gcc's) and that
>   should probably also go into default profiles.
> * Furthermore hardened disables some useful features due to their
>   incompatibility with pax (e.g. sanitizers).
> 
> So it's stuff that either is obsolete or probably should be a candidate
> for main profiles. Maybe we should strive for "hardened-by-default".
> 

You're forgetting selinux.  Most of Zorry's work has made it into gcc
and is now being enabled by our default toolchain.  Some kernel features
have also been improved upstream.  With upstream carrying a lot of the
work we did, I think 'hardened-by-default' minus selinux should be the
goal of Gentoo.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA


  reply	other threads:[~2018-04-16 12:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-16  0:04 [gentoo-dev] Regarding the State of PaX in the tree Anthony G. Basile
2018-04-16  1:25 ` R0b0t1
2018-04-16  2:25 ` Sam Jorna
2018-04-16  6:06 ` Michał Górny
2018-04-16  7:22   ` Ulrich Mueller
2018-04-16 12:20     ` Anthony G. Basile
2018-04-16  8:05 ` Marc Schiffbauer
2018-04-16 12:12   ` Anthony G. Basile
2018-04-16 17:11     ` Patrick McLean
2018-04-19 12:05     ` Marc Schiffbauer
2018-04-16  9:14 ` Hanno Böck
2018-04-16 12:31   ` Anthony G. Basile [this message]
2018-04-16 14:26     ` Francesco Riosa
2018-04-16 17:53   ` Toralf Förster
2018-04-16 18:16     ` Jason Zaman

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=2d1d9b97-184b-3636-d920-5d1cbadb624e@gentoo.org \
    --to=blueness@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox