Hardening flags

Russ Allbery eagle at eyrie.org
Thu Nov 12 05:01:14 UTC 2020


Julien ÉLIE <julien at trigofacile.com> writes:

> Suggested addition in configure.ac:

> dnl Add hardening flags, if supported by the compiler.
> INN_PROG_CC_FLAG([-fPIE], [CFLAGS="${CFLAGS} -fPIE"
>                            LDFLAGS="${LDFLAGS} -fPIE -pie"], [])
> INN_PROG_CC_FLAG([-fstack-protector-strong],
>                  [CFLAGS="${CFLAGS} -fstack-protector-strong"], [])

This looks fine for the stack protector flag.  I'm not sure about PIE; it
seems to be rather complicated.  The dpkg-buildflags documentation says:

    If there is a need to set these flags manually, bypassing the gcc
    specs injection, there are several things to take into account.
    Unconditionally and explicitly passing -fPIE, -fpie or -pie to a
    build-system using libtool is safe as these flags will get stripped
    when building shared libraries.  Otherwise on projects that build
    both programs and shared libraries you might need to make sure that
    when building the shared libraries -fPIC is always passed last (so
    that it overrides any previous -PIE) to compilation flags such as
    CFLAGS, and -shared is passed last (so that it overrides any
    previous -pie) to linking flags such as LDFLAGS. Note: This should
    not be needed with the default gcc specs machinery.

> However, when building the test suite with -fPIE, I encounter an error:

> ../libtool --mode=link gcc -fPIE -pie
> -L/home/iulius/work/cyrus-install/lib  -o authprogs/ident.t
> authprogs/ident-t.o tap/basic.o /home/iulius/work/inn/trunk/lib/libinn.la
> libtool: link: gcc -fPIE -pie -o authprogs/.libs/ident.t
> authprogs/ident-t.o tap/basic.o  -L/home/iulius/work/cyrus-install/lib
> /home/iulius/work/inn/trunk/lib/.libs/libinn.so -Wl,-rpath
> -Wl,/home/iulius/work/test-inn-bdb/lib
> /usr/bin/ld: authprogs/ident-t.o: relocation R_X86_64_32 against
> `.rodata.str1.1' can not be used when making a shared object; recompile
> with -fPIC

I think the problem is that the tests Makefile doesn't use libtool to
compile the individual objects.  It just uses CC.  Therefore, it doesn't
get the -fPIE flag and therefore doesn't create position-independent
objects.  That's how I'd interpret that error.

However, I don't know why --with-pic=yes would fix this problem.  Maybe
that strips out -pie?  (In which case it would defeat the whole point.)
I'm also not sure why the same problem doesn't happen when building other
executables like innd, although I'll note those Makefiles don't seem to
specify a .c.o rule, whereas the tests Makefile does.  (But perl.o and
python.o are built with just CC, so... I'm confused.)

Honestly, a lot of things would be easier if we used Automake.  There's a
lot of very INN-specific Makefile machinery and I suspect that's breaking
somewhere.  But that's a whole other project.

> To handle commas, there's the following change to add to rra-c-util:

> --- m4/cc-flags.m4	(révision 10390)
> +++ m4/cc-flags.m4	(copie de travail)
> @@ -28,7 +28,7 @@

>  dnl Used to build the result cache name.
>  AC_DEFUN([_RRA_PROG_CC_FLAG_CACHE],
> -[translit([rra_cv_compiler_c_$1], [-=+], [___])])
> +[translit([rra_cv_compiler_c_$1], [-=+,], [____])])

>  dnl Check whether a given flag is supported by the compiler.
>  AC_DEFUN([RRA_PROG_CC_FLAG],

Done.

Syncing rra-c-util will also pick up the fix for Debian bug #974024.

-- 
Russ Allbery (eagle at eyrie.org)             <https://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.


More information about the inn-workers mailing list