| 1 |
On 10/24/2011 02:58 AM, "Paweł Hajdan, Jr." wrote: |
| 2 |
> |
| 3 |
>> How would we say, |
| 4 |
>> if you use gcc-config and choose gcc-4.5.1-hardened spec, mask |
| 5 |
>> gdb-7.0*? I don't think its impossible, but I'm not seeing how to |
| 6 |
>> proceed right now. |
| 7 |
> First, I'd like the hardened spec to be non-default, so that if the user |
| 8 |
> chooses the hardened spec he'd be "on his own", and expect possibly more |
| 9 |
> breakages. |
| 10 |
Well not totally on their own, they'd report it and we'd have to see |
| 11 |
what we want to do on an ad hoc basis. So maybe the first step would be |
| 12 |
to just build 5 specs: |
| 13 |
|
| 14 |
[1] x86_64-pc-linux-gnu-4.4.5 |
| 15 |
[2] x86_64-pc-linux-gnu-4.4.5-hardenednopie |
| 16 |
[3] x86_64-pc-linux-gnu-4.4.5-hardenednopiessp |
| 17 |
[4] x86_64-pc-linux-gnu-4.4.5-hardenednossp |
| 18 |
[5] x86_64-pc-linux-gnu-4.4.5-vanilla |
| 19 |
|
| 20 |
Here [1] = fully hardened. Then ship with no other changes. When bug |
| 21 |
start to come in, you can deal with each --- some may be fixes at the |
| 22 |
package level (usually the build system), some may be ebuild fixes, some |
| 23 |
may need to go into the profiles. |
| 24 |
|
| 25 |
There is one other catch Zorry pointed out, glibc. There are some |
| 26 |
patches against glibc which would have to go in unconditionally. Take a |
| 27 |
look at eblit-src_unpack-post() in glibc-2.12.2.ebuild. Currently |
| 28 |
they're if use hardened. That conditional would be removed. |
| 29 |
|
| 30 |
> Second, profiles/hardened/package.mask seems to contain only few |
| 31 |
> entries, and a more recent gdb than 7.0 works and is in stable. I've |
| 32 |
> checked on my hardened system. This doesn't seem to be a serious issue, |
| 33 |
> maybe we can just punt gdb 7.0 or print a message that it's expected to |
| 34 |
> be broken with hardened spec. |
| 35 |
|
| 36 |
Those profiles have some ancient stuff in them which we know about, but |
| 37 |
haven't removed for legacy reasons. You want to look at the files under |
| 38 |
profiles/hardened/linux/ What would wind up happening if hardened goes |
| 39 |
mainstream is that those profiles would be reduced to just the |
| 40 |
maskings/unmaskings for a pax hardened kernel. Selinux has its own. |
| 41 |
|
| 42 |
> Third - can we forcefully disable hardened features in packages that are |
| 43 |
> not compatible? My assumption is yes, and we should probably print a |
| 44 |
> warning then. |
| 45 |
|
| 46 |
There are a few things you can do here, yes. It is always possible to |
| 47 |
turn off hardening because the *last* resort solution is just switch |
| 48 |
compile specs in the ebuild. This is only if none of the other methods |
| 49 |
work, the best method being fix the build system so you can switch the |
| 50 |
feature off in configure. I had to use it once for virtualbox which has |
| 51 |
a brain dead build system. There we warn the user to switch specs in |
| 52 |
pkg_setup() using ... if built_with_use sys-devel/gcc hardened. |
| 53 |
|
| 54 |
|
| 55 |
> Fourth - we can add the gcc spec to emerge --info. |
| 56 |
> |
| 57 |
> What do you think? |
| 58 |
> |
| 59 |
Good idea. |
| 60 |
|
| 61 |
|
| 62 |
-- |
| 63 |
Anthony G. Basile, Ph.D. |
| 64 |
Gentoo Linux Developer [Hardened] |
| 65 |
E-Mail : blueness@g.o |
| 66 |
GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 |
| 67 |
GnuPG ID : D0455535 |
Archives