From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RIIg3-0003aN-7D for garchives@archives.gentoo.org; Mon, 24 Oct 2011 11:26:47 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8270521C05C; Mon, 24 Oct 2011 11:26:38 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 95C1321C025 for ; Mon, 24 Oct 2011 11:26:12 +0000 (UTC) Received: from eduroam-10-20-4-61.mimuw.edu.pl (fw-gw-atm.mimuw.edu.pl [193.0.96.15]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: phajdan.jr) by smtp.gentoo.org (Postfix) with ESMTPSA id 7AB571B4004 for ; Mon, 24 Oct 2011 11:26:11 +0000 (UTC) Message-ID: <4EA54B49.9050503@gentoo.org> Date: Mon, 24 Oct 2011 13:26:01 +0200 From: =?UTF-8?B?IlBhd2XFgiBIYWpkYW4sIEpyLiI=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Building hardened gcc specs always, just not enabling them by default References: <4EA45652.1050309@gentoo.org> <4EA464F2.4040203@gentoo.org> <4EA46F53.10400@gentoo.org> <4EA50CB1.50308@gentoo.org> <4EA544E7.1040905@gentoo.org> In-Reply-To: <4EA544E7.1040905@gentoo.org> X-Enigmail-Version: 1.3.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1313DA95EA77656D29ACA125" X-Archives-Salt: X-Archives-Hash: 2f56f6cb80e2370d034cc65fb463fda5 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1313DA95EA77656D29ACA125 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/24/11 12:58 PM, Anthony G. Basile wrote: > Well not totally on their own, they'd report it and we'd have to see > what we want to do on an ad hoc basis. Fair enough, that's why I suggested to make the hardened spec non-default, so that they have to switch it, and include the info in emerge --info so we can identify the reason. > So maybe the first step would be > to just build 5 specs: >=20 > [1] x86_64-pc-linux-gnu-4.4.5 > [2] x86_64-pc-linux-gnu-4.4.5-hardenednopie > [3] x86_64-pc-linux-gnu-4.4.5-hardenednopiessp > [4] x86_64-pc-linux-gnu-4.4.5-hardenednossp > [5] x86_64-pc-linux-gnu-4.4.5-vanilla >=20 > Here [1] =3D fully hardened. Then ship with no other changes. When bu= g > start to come in, you can deal with each --- some may be fixes at the > package level (usually the build system), some may be ebuild fixes, som= e > may need to go into the profiles. Right, this is exactly what I'm suggesting, just make [5] the default or do some juggling so that [1] is vanilla and [5] is fully hardened or something like that. > There is one other catch Zorry pointed out, glibc. There are some > patches against glibc which would have to go in unconditionally. Take = a > look at eblit-src_unpack-post() in glibc-2.12.2.ebuild. Currently > they're if use hardened. That conditional would be removed. Ah, ok. So we have another one. Let's find out our exact constraints: 1. Are those glibc patches required for gcc built with hardened support? Will the gcc build fail without them, or will things fail at runtime without them? 2. Enabling glibc patches would mean enabling PIC by default, right? Is that OK? Can it cause breakages? 3. Am I reading things correctly that PIE is _not_ enabled by default, but only when _using_ (i.e. active, not just built) PIE-enabled gcc specs= ? > Those profiles have some ancient stuff in them which we know about, but= > haven't removed for legacy reasons. Please note I've checked on my hardened system and the file I cited has been used and provided as the mask reason. Maybe it's ancient, but it's still in use. > You want to look at the files under > profiles/hardened/linux/ What would wind up happening if hardened goes= > mainstream is that those profiles would be reduced to just the > maskings/unmaskings for a pax hardened kernel. Selinux has its own. Sounds good. By the way, if you're concerned about masking things and so on - why are hardened-sources _not_ masked on non-hardened profiles? There are two ways to get an invalid mix of hardened kernel and incompatible packages: a) hardened profile + trying to emerge incompatible packages (this is currently blocked by p.mask entries) b) normal profile + incompatible packages + hardened-sources (not blocked= ) >> Third - can we forcefully disable hardened features in packages that a= re >> not compatible? My assumption is yes, and we should probably print a >> warning then. >=20 > There are a few things you can do here, yes. It is always possible to > turn off hardening because the *last* resort solution is just switch > compile specs in the ebuild. Do you mean calling gcc-config here or something else? If gcc-config, it'd be quite hacky and fragile (parallel building of multiple packages, having multiple versions of gcc installed). Is it possible to just pass flags to GCC: disable all this hardened stuff? I know you can disable stack protector, but how about PIE or PIC, and possible other hardening features? > This is only if none of the other methods > work, the best method being fix the build system so you can switch the > feature off in configure. I had to use it once for virtualbox which ha= s > a brain dead build system. There we warn the user to switch specs in > pkg_setup() using ... if built_with_use sys-devel/gcc hardened. Ah, so it tells the user to switch gcc profile and dies. :-/ Well, in my opinion we could get rid of virtualbox anyway (p.mask it everywhere), I think it has been tainted in the kernel as crap. --------------enig1313DA95EA77656D29ACA125 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAk6lS08ACgkQuUQtlDBCeQI1ugCggPrvDkbW4FVVrEqnPvGfh/4l Ho4AnjmGHJtddluYNAQ+4NYU0/r9SAnT =uA9T -----END PGP SIGNATURE----- --------------enig1313DA95EA77656D29ACA125--