_hardened_build not affecting libtool-compiled libraries

Richard W.M. Jones rjones at redhat.com
Mon Jun 24 19:47:46 UTC 2013


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 at redhat.com> 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


More information about the devel mailing list