Bug#656656: Please enabled hardened build flags

[Moritz Mühlenhoff]

On Fri, Jan 27, 2012 at 10:00:53AM -0800, Russ Allbery wrote:
> Russ Allbery <rra at debian.org> writes:
> > "Cantor, Scott" <cantor.2 at osu.edu> writes:
> 
> >> Not that it's necessarily likely here, but with the --silent flag on to
> >> limit noise, you actually can't tell what the actual compiler command
> >> is.  There are libtool bugs, usually on Solaris one finds, that break
> >> the use of some flags. I guess it's possible something like that could
> >> be happening.
> 
> > True.  Okay, let me go do a manual build where I can remove --silent and
> > be sure that things are actually being passed down to the compiler.
> 
> Without --silent, libtool definitely claims to be sending that flag:
> 
> /bin/bash ../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I..   -pthread -g -Wall -O2 -O2 -DNDEBUG -D_FORTIFY_SOURCE=2    -pthread -Wall -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -O2 -DNDEBUG -c -o AbstractComplexElement.lo AbstractComplexElement.cpp
> libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -pthread -g -Wall -O2 -O2 -DNDEBUG -D_FORTIFY_SOURCE=2 -pthread -Wall -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -O2 -DNDEBUG -c AbstractComplexElement.cpp  -fPIC -DPIC -o .libs/AbstractComplexElement.o
> 
> and I suspended the build in the middle of compiling a source file, and
> that flag is there in the process arguments:
> 
> eagle     9987  0.0  0.0   2088   512 pts/10   T    09:54   0:00 g++ -DHAVE_CONFIG_H -I. -I.. -pthread -g -Wall -O2 -O2 -DNDEBUG -D_FORTIFY_SOURCE=2 -pthread -Wall -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -O2 -DNDEBUG -c AbstractComplexElement.cpp -fPIC -DPIC -o .libs/AbstractComplexElement.o
> 
> but hardening-check returns the same result:
> 
> windlord:~/dvl/debian/xmltooling> hardening-check xmltooling/.libs/libxmltooling.so
> xmltooling/.libs/libxmltooling.so:
>  Position Independent Executable: no, regular shared library (ignored)
>  Stack protected: yes
>  Fortify Source functions: no, no protected functions found!
>  Read-only relocations: yes
>  Immediate binding: no not found!
> 
> so if there's a failure here, it seems to be somewhere inside g++, or a
> need to include more than just -D_FORTIFY_SOURCE=2 to enable this.

Hmm, I'm not sure what's wrong here.

I'm adding Kees Cook to CC. Kees, did you see similar issues with C++
on Ubuntu when g++ was patched to use FORTIFY_SOURCE by default?
This is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656656

 > (Moritz, do you know if bindnow is safe for shared libraries?  I know pie
> isn't, since it conflicts with PIC, but I've only been omitting bindnow
> because I wasn't sure.  I'm not concerned with the possible performance
> issues; startup cost isn't significant for the known users of these
> libraries.)

It should be safe. It only slightly increases the startup time, since all
symbols need to be resolved.

Cheers,
        Moritz