Re: Updated patch for pkgsrc hardening

[Pierre Pronchery <khorben%defora.org@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/03/16 02:47, Pierre Pronchery wrote:
> I attached a new version of the patch here.

While investigating some more, I found this wiki page from Debian on
how they are tackling the exact same issues:
https://wiki.debian.org/Hardening

Great read.

For PIE in particular, it seems that setting LDFLAGS to "-pie" is more
portable than "-Wl,-pie"; it works equally well for me (with a single
package) on:
- - NetBSD 7/amd64 (GCC),
- - NetBSD 7/i386 (GCC),
- - Debian Linux 6/amd64 (GCC),
- - Debian Linux 6/i386 (GCC),
- - FreeBSD 10.1/amd64 (Clang),
- - FreeBSD 10.1/i386 (Clang),
- - and OpenBSD 5.8/i386 (GCC and Clang) (hi devio.us!)

Reading its manual page, it looks like gcc(1) is able to decide on its
own when "-shared-libgcc" should be considered implied or not.

I will update my patch to reflect this.

Cheers,
- -- khorben

> On 03/01/16 03:23, Greg Troxel wrote:
>> Do you have a plan for how this will be extended to more 
>> compilers/platforms?  I'd like to understand that before we
>> start.
> 
> Nope. I cannot have a plan for compilers or platforms that I do not
> know and actively use. That's why I'm starting by communicating and
> showing my work, and as you can see, with input from others and
> jperkin@ in particular here, the plan builds itself and we all
> learn.
> 
>> I am curious what kind of testing this has received.  Have you
>> done bulk builds with this?  On which platforms?  Have the
>> programs had their tests run ('make test'), and are there
>> regressions?   What compilers have been tested with this besides
>> gcc?  Certainly clang matters.  But if you are saying that no
>> behavior will change except for netbsd/gcc, that's probably ok.
> 
> I have been running pkgsrc-2015Q2 with these patches for almost a
> year (I started around the 2015Q1 release). In the current state,
> the behavior only affects NetBSD/gcc on specific platforms, and on
> SunOS where tested by jperkin@.
> 
>> This adds things to wrappers, but what about cwrappers?  We are
>> nearing flipping to cwrappers by default, which I think means
>> that we are in a period where changes have to apply to both.
>> Also, the new wrapper seems to open-code flags, making it harder
>> to maintain this and to port to clang.
> 
> I have never had the chance to look at cwrappers yet. I do not
> know if/what changes there in this context. I have integrated the
> changes reported in this thread though.
> 
>> I would like to see this separated into adding mechanisms that
>> don't behave differently by default and later changing the
>> defaults, so that people can easily experiment locally, rather
>> than having the new behavior hit everyone right away.
> 
> That is my intention too.
> 
>> +#PKGSRC_MKPIE?= yes
>> 
>> +.if ${PKGSRC_MKPIE:Uyes} != "no"
>> 
>> I find this style confusing (moving the default into the test,
>> [...]
> 
> I tried to reproduce and stick the idioms already in place. I
> updated the patch with the suggestions from jperkin@.
> 
> The rationale is that I don't want to give false promises and let
> the user set "yes" and then have the feature(s) be silently ignored
> because the platform used is not actually supported. Misplaced
> impression of security is worse than no security at all. I still
> have some concerns there, but also better is the enemy of good -
> sometimes it is best to do something imperfect, than not do it at
> all. Failing to build is more secure than a bad package. But so is
> a computer without power. *mindcrash*
> 
>> So all I all I'd like:
>> 
>> to hear the long-term plan (other platforms, other compilers)
> 
> Listen to suggestions and complaints, and consider and address
> them.
> 
>> to avoid the yes=no make-optimization
> 
> I think this looks better now; let me know.
> 
>> to figure out about cwrappers
> 
> I believe the behavior with cwrappers is not affected at the
> moment, except where tested by jperkin@. I welcome help here.
> 
>> to have this be just adding features that can be turned on, not 
>> changing defaults
> 
> That is fine for me: the actual import to pkgsrc will be easier
> for everyone with these new options disabled initially. The patch
> attached here is still a work in progress, in the context of the
> EdgeBSD project.
> 
> HTH,
> 


- -- 
khorben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJW2MabAAoJEDA4y9uYhpcD/ooQAMn+FIR3jwJdAsVcAsCAUX88
QGZ8fQC30td91yFXET8VQ/QI4u9Pus35oCWqv1ENYpJe6HIJ2fR1JQw5v+iqijzD
hB5IBxLuPTkE8rdd+/5JhO+rGsfMOLeQ62i9xFxaAYrWfsqBoxvW9G6V5AxIqd6c
ngcVboHmgv3Lmh8kQKIiBptn0RbE790Dmby9xDTG7Fb9fq3R/tnVL1DbRoKf5vZx
BLasgPt4kNGBNAW22rSl2/rnEQMOFkA5ew2ewRSBVBK/72bdpZhXmztJGVDiwoJ6
G32LElHZNRV/YVDfTMtUO6V38bywFymNyTC8hpqDnkVvAOl1AkeoCnaCjBj2wqOj
iSXiprC7n6N7eP7C5BnhKxGaDoosc+I4iPraOchRjUrRml+NYIqKkKh4tuGDTHQQ
uFUOaBKyS8qtxv9elGmtC8ZH28jvUsCnEUMVDD/8njQdcjENatu0i4hO+vmoyUrt
VDjyRG+u4SHioEq22hsiVr+mujbG5xQmqU+XufkwNSDtymrMFar8jEhWsehUahDw
sgsaDKohlhMvObhX/YCiUHC2Fgcaxt7AriI/gFdqK8WEWy10yrOIEugk5yKroW/m
hNGQE76VmiLaIVKwK8eMLzvbvVJK2yfdJ/RJOTX6oe3lr4FAT/QjzXwVAsOOO37q
liT+9p3mL/i42skxeFLw
=cKNC
-----END PGP SIGNATURE-----