_hardened_build not affecting libtool-compiled libraries

[Richard W.M. Jones]

Here's the problem (found by Björn Esser):

  https://bugzilla.redhat.com/show_bug.cgi?id=977446#c10

and then later on:

  https://bugzilla.redhat.com/show_bug.cgi?id=977446#c14

So it seems as if _hardened_build for some reason doesn't work for
libtool-compiled libraries.  It does look as if the correct CFLAGS and
LDFLAGS are getting to the build.  See for example:

  http://koji.fedoraproject.org/koji/buildinfo?buildID=429062
 
http://kojipkgs.fedoraproject.org//packages/nbdkit/1.0.0/4.fc20/data/logs...

but the plugins from that build are not hardened fully:

  $ hardening-check ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so
  ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so:
   Position Independent Executable: no, regular shared library (ignored)
   Stack protected: no, not found!
   Fortify Source functions: no, only unprotected functions found!
   Read-only relocations: yes
   Immediate binding: yes

Also we had to add an LDFLAGS hack into the %build section to even get
this far.

Any ideas?  Is this a bug or how it should be?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

[Miloslav Trmač]

On Mon, Jun 24, 2013 at 8:46 PM, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote:
>  but the plugins from that build are not hardened fully:
Isn't it possible that the plugins are just so trivial that there were
no opportunities for hardening?

>    $ hardening-check
> ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so
>    ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so:
>     Position Independent Executable: no, regular shared library (ignored)
>     Stack protected: no, not found! 
No on-stack arrays that I can find.

>     Fortify Source functions: no, only unprotected functions found!
I can see libc calls with compile-time-known destination sizes except
for example1_load () where it can be statically proven the call is
safe.
    Mirek

[Richard W.M. Jones]

On Mon, Jun 24, 2013 at 09:13:29PM +0200, Miloslav Trmač wrote:
>  On Mon, Jun 24, 2013 at 8:46 PM, Richard W.M. Jones
> <rjones(a)redhat.com&gt; wrote:
>  > but the plugins from that build are not hardened fully:
>  Isn't it possible that the plugins are just so trivial that there were
>  no opportunities for hardening?
>  
>  >   $ hardening-check ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so
>  >   ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so:
>  >    Position Independent Executable: no, regular shared library (ignored)
>  >    Stack protected: no, not found!
>  No on-stack arrays that I can find.
>  
>  >    Fortify Source functions: no, only unprotected functions found!
>  I can see libc calls with compile-time-known destination sizes except
>  for example1_load () where it can be statically proven the call is
>  safe. 
Yes, I think you're right.  I only checked the simple example*
plugins.  The xz plugin which is rather more complicated does seem to
be protected:

$ hardening-check ./usr/lib64/nbdkit/plugins/nbdkit-xz-plugin.so 
./usr/lib64/nbdkit/plugins/nbdkit-xz-plugin.so:
 Position Independent Executable: no, regular shared library (ignored)
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)

[Richard W.M. Jones]

On Mon, Jun 24, 2013 at 08:46:51PM +0100, Richard W.M. Jones wrote:
>  On Mon, Jun 24, 2013 at 09:13:29PM +0200, Miloslav Trmač wrote:
>  > On Mon, Jun 24, 2013 at 8:46 PM, Richard W.M. Jones <rjones(a)redhat.com&gt;
> wrote:
>  > > but the plugins from that build are not hardened fully:
>  > Isn't it possible that the plugins are just so trivial that there were
>  > no opportunities for hardening?
>  > 
>  > >   $ hardening-check ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so
>  > >   ./usr/lib64/nbdkit/plugins/nbdkit-example1-plugin.so:
>  > >    Position Independent Executable: no, regular shared library (ignored)
>  > >    Stack protected: no, not found!
>  > No on-stack arrays that I can find.
>  > 
>  > >    Fortify Source functions: no, only unprotected functions found!
>  > I can see libc calls with compile-time-known destination sizes except
>  > for example1_load () where it can be statically proven the call is
>  > safe.
>  
>  Yes, I think you're right.  I only checked the simple example*
>  plugins.  The xz plugin which is rather more complicated does seem to
>  be protected:
>  
>  $ hardening-check ./usr/lib64/nbdkit/plugins/nbdkit-xz-plugin.so 
>  ./usr/lib64/nbdkit/plugins/nbdkit-xz-plugin.so:
>   Position Independent Executable: no, regular shared library (ignored)
>   Stack protected: yes
>   Fortify Source functions: yes (some protected functions found)
>   Read-only relocations: yes
>   Immediate binding: yes 
Note there is still a problem that an LDFLAGS hack was needed in the
spec file, otherwise libtool (or something) eats the hardening LDFLAGS.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

[Reindl Harald]

Am 24.06.2013 21:47, schrieb Richard W.M. Jones:
> > $ hardening-check ./usr/lib64/nbdkit/plugins/nbdkit-xz-plugin.so
>
> > ./usr/lib64/nbdkit/plugins/nbdkit-xz-plugin.so:
> >  Position Independent Executable: no, regular shared library (ignored)
> >  Stack protected: yes
> >  Fortify Source functions: yes (some protected functions found)
> >  Read-only relocations: yes
> >  Immediate binding: yes
>  
>  Note there is still a problem that an LDFLAGS hack was needed in the
>  spec file, otherwise libtool (or something) eats the hardening LDFLAGS 
IMHO the hardening macro should always step in directly before
%configure becaus it does also not work with rpmrc not importing
the distribution defaults (for good reasons)

[builduser@buildserver64:~]$ cat /home/builduser/.rpmrc
optflags: x86_64 -m64 -O3 -march=corei7 -mtune=corei7 -fopenmp -mmmx -msse2 -msse3
-msse4.1 -msse4.2 -maes -pipe
-fstack-protector --param=ssp-buffer-size=4 -mfpmath=sse -D_FORTIFY_SOURCE=2 -fexceptions

that is why is witched on my private build-environments to manually
set all the FLAGS and avoid the hardening-macro at all

[builduser@buildserver64:~]$ cat /rpmbuild/SPECS/dovecot.spec | grep FLAGS
export CFLAGS="%{optflags} -fPIC -fPIE -funroll-loops -fstack-protector-all"
export CXXFLAGS="%{optflags} -fPIC -fPIE -funroll-loops -fstack-protector-all"
export FFLAGS="%{optflags} -fPIC -fPIE -funroll-loops -fstack-protector-all"
export CPPFLAGS="%{optflags} -fPIC -fPIE -funroll-loops -fstack-protector-all"
export LDFLAGS="-Wl,-z,now -Wl,-z,relro,-z,noexecstack -pie"
export SH_LDFLAGS="-Wl,-z,now -Wl,-z,relro,-z,noexecstack -pie"

[Paul Wouters]

On Mon, 24 Jun 2013, Richard W.M. Jones wrote:

>  Note there is still a problem that an LDFLAGS hack was needed in the
>  spec file, otherwise libtool (or something) eats the hardening LDFLAGS. 
Too often Makefiles contain CFLAGS= / LDFLAGS=, instead of CFLAGS?= / LDFLAGS?=

Paul

[Richard W.M. Jones]

On Mon, Jun 24, 2013 at 07:39:59PM -0400, Paul Wouters wrote:
>  On Mon, 24 Jun 2013, Richard W.M. Jones wrote:
>  
>  >Note there is still a problem that an LDFLAGS hack was needed in the
>  >spec file, otherwise libtool (or something) eats the hardening LDFLAGS.
>  
>  Too often Makefiles contain CFLAGS= / LDFLAGS=, instead of CFLAGS?= / LDFLAGS?= 
It's using autotools.  The sources are linked from the bug report
and here:

https://github.com/libguestfs/nbdkit/

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)

[Björn Esser]

Am Dienstag, den 25.06.2013, 08:29 +0100 schrieb Richard W.M. Jones:
>  On Mon, Jun 24, 2013 at 07:39:59PM -0400, Paul Wouters wrote:
>  > On Mon, 24 Jun 2013, Richard W.M. Jones wrote:
>  > 
>  > >Note there is still a problem that an LDFLAGS hack was needed in the
>  > >spec file, otherwise libtool (or something) eats the hardening LDFLAGS.
>  > 
>  > Too often Makefiles contain CFLAGS= / LDFLAGS=, instead of CFLAGS?= / LDFLAGS?=
>  
>  It's using autotools.  The sources are linked from the bug report
>  and here:
>  
>  https://github.com/libguestfs/nbdkit/ 
Hi Rich!

Sorry, I faded away yesterday. I had an appointment with my new
sponsoree, so I was busy rest of the day.

The LDFLAGS-Hack in rpm-spec is needed because "libcrap" purges {C,
LD}FLAGS, which it thinks are not of use for the linker.  The
"-spec=..."-cli-switch from gcc is such a case.  The "-Wl,z,now"-flag
is
expanded from such a gcc-spec, but libtool doesn't pass it, because of
the explained behaviour.

This is a, not fixed yet, bug in libtool know for years.
See: http://bit.ly/15Bnye5

Cheers,
  Björn