Hardening flags

Julien ÉLIE julien at trigofacile.com
Thu Nov 12 22:55:37 UTC 2020


Hi Russ,

>> 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.

Indeed, in the libtool script, these rules are correctly enforced.



>> ../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.

Exact, the -fPIE flag was not set.  Problem spotted:  build flags were 
inconsistent when using "make warnings".  Another variable (CC_WARNINGS) 
should have been set:

INN_PROG_CC_FLAG([-fPIE], [CFLAGS="${CFLAGS} -fPIE"
                            CC_WARNINGS="${CC_WARNINGS} -fPIE"
                            LDFLAGS="${LDFLAGS} -fPIE -pie"], [])

Now builds fine!



> However, I don't know why --with-pic=yes would fix this problem.

Because I ran "make" without warnings on that time, to have less output 
on the screen...
So, no, it does not fix the problem.



> 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.)

Seems like only lib, storage and history directories use libtool for 
compiling (the 3 libraries we generate).  All the other directories use 
CC directly for compiling.
For linking, libtool is always use.


Hmm, the rule for lib/perl.c differs from the others in lib/Makefile:
.c.o .c.lo:
         $(LIBCC) $(CFLAGS) -c $*.c

perl.o: perl.c
         $(CC) $(CFLAGS) $(PERL_CPPFLAGS) $(LDFLAGS) -c perl.c

Maybe it should also use LIBCC (with its specific PERL_CPPFLAGS).



> 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.

A remaining issue is a build with "--with-pic=no".
It fails with "can not be used when making a shared object; recompile 
with -fPIC".
So I try "--with-pic=no --enable-shared=no" and there are a few things 
to investigate further (multiple definitions, undefined references...). 
  Well, it seems that INN does not currently build with static libraries!

As a matter of fact, we have in nnrpd.h and ovinterface.h:
  extern char *ACTIVE;
So the one in nnrpd should be renamed.

ovdb does not build:
/home/iulius/work/gcc/gcc-10.1.0/bin/gcc -fPIE -pie -o ovdb_init 
ovdb_init.o  /home/iulius/work/inn/trunk/history/.libs/libinnhist.a 
/home/iulius/work/inn/trunk/storage/.libs/libstorage.a 
/home/iulius/work/inn/trunk/lib/.libs/libinn.a -ldb -lz
/home/iulius/work/inn/trunk/storage/.libs/libstorage.a(expire.o): dans 
la fonction « OVhisthasmsgid »:
/home/iulius/work/inn/trunk/storage/expire.c:804: référence indéfinie 
vers « HISlookup »

I'll go on fixing that tomorrow.



As for now, it seems that the following lines are enough to correctly 
build INN with PIE support and libtool.
           INN_PROG_CC_FLAG([-fPIE], [CFLAGS="${CFLAGS} -fPIE"
                            CC_WARNINGS="${CC_WARNINGS} -fPIE"
                            LDFLAGS="${LDFLAGS} -fPIE -pie"], [])

-- 
Julien ÉLIE

« – Nous parlerons quand l'interprète dormira. [Bong !]
   – Il dort. On peut parler. » (Astérix)


More information about the inn-workers mailing list