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: > > [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 > > Here [1] = fully hardened. Then ship with no other changes. When bug > 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, some > 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 are >> not compatible? My assumption is yes, and we should probably print a >> warning then. > > 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 has > 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. <https://lkml.org/lkml/2011/10/6/317>
signature.asc
Description: OpenPGP digital signature
