| 1 |
On 10/24/11 12:58 PM, Anthony G. Basile wrote: |
| 2 |
> Well not totally on their own, they'd report it and we'd have to see |
| 3 |
> what we want to do on an ad hoc basis. |
| 4 |
|
| 5 |
Fair enough, that's why I suggested to make the hardened spec |
| 6 |
non-default, so that they have to switch it, and include the info in |
| 7 |
emerge --info so we can identify the reason. |
| 8 |
|
| 9 |
> So maybe the first step would be |
| 10 |
> to just build 5 specs: |
| 11 |
> |
| 12 |
> [1] x86_64-pc-linux-gnu-4.4.5 |
| 13 |
> [2] x86_64-pc-linux-gnu-4.4.5-hardenednopie |
| 14 |
> [3] x86_64-pc-linux-gnu-4.4.5-hardenednopiessp |
| 15 |
> [4] x86_64-pc-linux-gnu-4.4.5-hardenednossp |
| 16 |
> [5] x86_64-pc-linux-gnu-4.4.5-vanilla |
| 17 |
> |
| 18 |
> Here [1] = fully hardened. Then ship with no other changes. When bug |
| 19 |
> start to come in, you can deal with each --- some may be fixes at the |
| 20 |
> package level (usually the build system), some may be ebuild fixes, some |
| 21 |
> may need to go into the profiles. |
| 22 |
|
| 23 |
Right, this is exactly what I'm suggesting, just make [5] the default or |
| 24 |
do some juggling so that [1] is vanilla and [5] is fully hardened or |
| 25 |
something like that. |
| 26 |
|
| 27 |
> There is one other catch Zorry pointed out, glibc. There are some |
| 28 |
> patches against glibc which would have to go in unconditionally. Take a |
| 29 |
> look at eblit-src_unpack-post() in glibc-2.12.2.ebuild. Currently |
| 30 |
> they're if use hardened. That conditional would be removed. |
| 31 |
|
| 32 |
Ah, ok. So we have another one. Let's find out our exact constraints: |
| 33 |
|
| 34 |
1. Are those glibc patches required for gcc built with hardened support? |
| 35 |
Will the gcc build fail without them, or will things fail at runtime |
| 36 |
without them? |
| 37 |
|
| 38 |
2. Enabling glibc patches would mean enabling PIC by default, right? Is |
| 39 |
that OK? Can it cause breakages? |
| 40 |
|
| 41 |
3. Am I reading things correctly that PIE is _not_ enabled by default, |
| 42 |
but only when _using_ (i.e. active, not just built) PIE-enabled gcc specs? |
| 43 |
|
| 44 |
> Those profiles have some ancient stuff in them which we know about, but |
| 45 |
> haven't removed for legacy reasons. |
| 46 |
|
| 47 |
Please note I've checked on my hardened system and the file I cited has |
| 48 |
been used and provided as the mask reason. Maybe it's ancient, but it's |
| 49 |
still in use. |
| 50 |
|
| 51 |
> You want to look at the files under |
| 52 |
> profiles/hardened/linux/ What would wind up happening if hardened goes |
| 53 |
> mainstream is that those profiles would be reduced to just the |
| 54 |
> maskings/unmaskings for a pax hardened kernel. Selinux has its own. |
| 55 |
|
| 56 |
Sounds good. By the way, if you're concerned about masking things and so |
| 57 |
on - why are hardened-sources _not_ masked on non-hardened profiles? |
| 58 |
|
| 59 |
There are two ways to get an invalid mix of hardened kernel and |
| 60 |
incompatible packages: |
| 61 |
|
| 62 |
a) hardened profile + trying to emerge incompatible packages (this is |
| 63 |
currently blocked by p.mask entries) |
| 64 |
|
| 65 |
b) normal profile + incompatible packages + hardened-sources (not blocked) |
| 66 |
|
| 67 |
>> Third - can we forcefully disable hardened features in packages that are |
| 68 |
>> not compatible? My assumption is yes, and we should probably print a |
| 69 |
>> warning then. |
| 70 |
> |
| 71 |
> There are a few things you can do here, yes. It is always possible to |
| 72 |
> turn off hardening because the *last* resort solution is just switch |
| 73 |
> compile specs in the ebuild. |
| 74 |
|
| 75 |
Do you mean calling gcc-config here or something else? If gcc-config, |
| 76 |
it'd be quite hacky and fragile (parallel building of multiple packages, |
| 77 |
having multiple versions of gcc installed). |
| 78 |
|
| 79 |
Is it possible to just pass flags to GCC: disable all this hardened |
| 80 |
stuff? I know you can disable stack protector, but how about PIE or PIC, |
| 81 |
and possible other hardening features? |
| 82 |
|
| 83 |
> This is only if none of the other methods |
| 84 |
> work, the best method being fix the build system so you can switch the |
| 85 |
> feature off in configure. I had to use it once for virtualbox which has |
| 86 |
> a brain dead build system. There we warn the user to switch specs in |
| 87 |
> pkg_setup() using ... if built_with_use sys-devel/gcc hardened. |
| 88 |
|
| 89 |
Ah, so it tells the user to switch gcc profile and dies. :-/ |
| 90 |
|
| 91 |
Well, in my opinion we could get rid of virtualbox anyway (p.mask it |
| 92 |
everywhere), I think it has been tainted in the kernel as crap. |
| 93 |
<https://lkml.org/lkml/2011/10/6/317> |
Archives