From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id C95E4139694 for ; Tue, 2 May 2017 19:58:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 53EABE0D9B; Tue, 2 May 2017 19:58:40 +0000 (UTC) Received: from mail-ua0-x244.google.com (mail-ua0-x244.google.com [IPv6:2607:f8b0:400c:c08::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 17B74E0D1A for ; Tue, 2 May 2017 19:58:39 +0000 (UTC) Received: by mail-ua0-x244.google.com with SMTP id j59so12273873uad.2 for ; Tue, 02 May 2017 12:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=OMKQXrxbRrvoKLXquKtn7+MBZbkqM7T+eMkNG+PZpIE=; b=mz5vifXqcjlw4zvXeBHl48lA2i7OZcR0xz6BuN5zK4PLf6A9AtBD0il+gvBUMv0eGa 7RrMZmq3lodoiI5usH9xznlGM6L0289cUd+tnF0N7grfmycoswhp4YNGR3E7w1rVwHqo 1F2oGDK1v+qGffXhTNQN6pmYHxuh6XMGT+uorILbXLTwWn0rYlQCVEI6wPPzq/kky+bG 27mMGpZteURDh60LI8zjEGKn84fOJR4PS0Kd9Z3exOZCIspTA8y9ouXOi8PGFiRJkGVj 9m5Il7bFETRtGmA5rYAGzQGbkkj7EC++9tvBpKqbiVQpLixWvVRezlBIeRURuileHYJQ HAfA== 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:content-transfer-encoding; bh=OMKQXrxbRrvoKLXquKtn7+MBZbkqM7T+eMkNG+PZpIE=; b=Yb21pGDdlQFfe9+RKPCAi5i1qjoR3HBDrjq+nMLsN7nmFYjNtP42VfsWqoFupvLS36 pm8a+LgPlFwbAUoodUov9cHk7nUoNmiySlYjOUibFBTY2fbRu7/7Zavcf+OnaZvpDjJS mz1HvTE8fRqU1o7153+FtiTHLaSwumWHnMiVdEjoNsXM8CIjaeCxUQ9cqaV7PB7QF9uD 4l+aPVz7E34WNjf9KyyvMIphf+8UrjLMkaZAAlqOTCFlxGkfchMGapX7rzRKiQljpMtu s3EiNwtw4BgSLdPuZovewhsR0b/rKSP8QsyDKk8vSZ6l9vqbaqjpskwlLgKGsw0ONOL7 fI9Q== X-Gm-Message-State: AN3rC/4voKQjrFGlQSr92nbxTVpX9aJcuUDC01kpWib4PHgRXx4tr6ca MyIGZMAAf+dNbl17FWdZqVQ0K1LiDf4nNr4= X-Received: by 10.176.24.167 with SMTP id t39mr5745846uag.79.1493755119023; Tue, 02 May 2017 12:58:39 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-hardened@lists.gentoo.org Reply-to: gentoo-hardened@lists.gentoo.org MIME-Version: 1.0 Received: by 10.176.9.205 with HTTP; Tue, 2 May 2017 12:58:18 -0700 (PDT) In-Reply-To: <10cb5e0cdaf9fdde9bcf74e803be66c8.squirrel@atoth.sote.hu> References: <20170501093843.GA927@gentoo.org> <20170502172820.43d6b720@gentp.lnet> <20170502180210.40df7f14@gentp.lnet> <10cb5e0cdaf9fdde9bcf74e803be66c8.squirrel@atoth.sote.hu> From: =?UTF-8?Q?Daniel_Cegie=C5=82ka?= Date: Tue, 2 May 2017 21:58:18 +0200 Message-ID: Subject: Re: [gentoo-hardened] Technical repercussions of grsecurity removal To: gentoo-hardened@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: f58759a8-829a-42b6-8519-871fe0284671 X-Archives-Hash: 114efeb4f24d7c97b5b450781503d7e6 2017-05-02 19:23 GMT+02:00 "T=C3=B3th Attila" : > 2017.M=C3=A1jus 2.(K) 18:59 id=C5=91pontban Daniel Cegie=C5=82ka ezt =C3= =ADrta: >>> pax.?mark actually, since the eclass helper is called pax-mark. :) >>> I'd hold off on removing those for at least a few months, though. >>> >> >> If PAX_MPROTECT returns (KSPP?), then ebuilds will need to be >> 'paxmarked' again. Years of work and PaX support ends in the trash. > > I must aggree here. If there will be an alternative implementation markin= g > may regain its meaning. The same binaries need to be marked in some way o= r > another. I wouldn't simply dump it unless it would disturb some > functionality. Even if PAX_MPROTECT somehow comes back to the kernel, there is no guarantee that it will be compatible with current PaX ELF header (elf_phdata->p_flags & PF_MPROTECT) or PAX_XATTR_FLAGS (PAX_MPROTECT=3D=3D0x04000000). Next, the PaX functionality are added to the kernel gradually: one functionality per patch (eg. PAX_USERCOPY -> HARDEN_USERCOPY). This means that any future solution will not be compatible with current PaX support. Again: years of work and PaX support ends in the trash.