Bug#654793: firebird2.5: Hardeneng flags not fully enabled
On 01/11/12 12:23, Damyan Ivanov wrote: -=| Alex Peshkoff, 11.01.2012 11:57:55 +0400 |=- On 01/10/12 21:17, Moritz Muehlenhoff wrote: On Tue, Jan 10, 2012 at 11:06:04AM +0200, Damyan Ivanov wrote: - The check for fortified source functions depends on the use of such functions. If none of them are present the error no protectable libc functions used is shown. However, there are also results that show no (e.g. /usr/bin/fbsvcmgr). As such, there might indeed be a problem with the LDFLAGS being overwritten. Most of the binaries suffer from this, and in the end the reason appears to be missing usage of CPPFLAGS when compiling C++ sources. That's correct. I've meant CPPFLAGS. CPreProcessorFLAGS when compiling C++ resources? I always use for it CXXFLAGS, which are taken into an account in firebird makefiles. http://stackoverflow.com/questions/495598/difference-between-cppflags-and-cxxflags-in-gnu-make CPP can pre-process all kinds of sources, C, C++, Fortran... and we want all of them to have that _FORTIFY_SOURCE=2 define. I think this is the reason to put it in CPPFLAGS -- to have it when pre-processing I've added support for CPPFLAGS. Moreover, now I use it internally for regular posix build (http://tracker.firebirdsql.org/browse/CORE-3727). So I hope you should not have problems with _FORTIFY_SOURCE. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654793: firebird2.5: Hardeneng flags not fully enabled
tags 654793 pending thanks -=| Alex Peshkoff, 12.01.2012 19:04:56 +0400 |=- I've added support for CPPFLAGS. Moreover, now I use it internally for regular posix build (http://tracker.firebirdsql.org/browse/CORE-3727). So I hope you should not have problems with _FORTIFY_SOURCE. Excellent! I am preparing package update using SVN's B2_5_Release branch. Thanks! signature.asc Description: Digital signature
Bug#654793: firebird2.5: Hardeneng flags not fully enabled
On 01/10/12 21:17, Moritz Muehlenhoff wrote: On Tue, Jan 10, 2012 at 11:06:04AM +0200, Damyan Ivanov wrote: - The check for fortified source functions depends on the use of such functions. If none of them are present the error no protectable libc functions used is shown. However, there are also results that show no (e.g. /usr/bin/fbsvcmgr). As such, there might indeed be a problem with the LDFLAGS being overwritten. Most of the binaries suffer from this, and in the end the reason appears to be missing usage of CPPFLAGS when compiling C++ sources. That's correct. I've meant CPPFLAGS. Cheers, Moritz CPreProcessorFLAGS when compiling C++ resources? I always use for it CXXFLAGS, which are taken into an account in firebird makefiles. http://stackoverflow.com/questions/495598/difference-between-cppflags-and-cxxflags-in-gnu-make -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654793: firebird2.5: Hardeneng flags not fully enabled
-=| Alex Peshkoff, 11.01.2012 11:57:55 +0400 |=- On 01/10/12 21:17, Moritz Muehlenhoff wrote: On Tue, Jan 10, 2012 at 11:06:04AM +0200, Damyan Ivanov wrote: - The check for fortified source functions depends on the use of such functions. If none of them are present the error no protectable libc functions used is shown. However, there are also results that show no (e.g. /usr/bin/fbsvcmgr). As such, there might indeed be a problem with the LDFLAGS being overwritten. Most of the binaries suffer from this, and in the end the reason appears to be missing usage of CPPFLAGS when compiling C++ sources. That's correct. I've meant CPPFLAGS. CPreProcessorFLAGS when compiling C++ resources? I always use for it CXXFLAGS, which are taken into an account in firebird makefiles. http://stackoverflow.com/questions/495598/difference-between-cppflags-and-cxxflags-in-gnu-make CPP can pre-process all kinds of sources, C, C++, Fortran... and we want all of them to have that _FORTIFY_SOURCE=2 define. I think this is the reason to put it in CPPFLAGS -- to have it when pre-processing all source files. As I understand it, CPPFLAGS is now taken into account when compiling plain C sources by pure luck -- the build system relies on the implicit rule for .c - .o compilation in 'make'. And since explicit rules are used for .cpp - .o compilation, CPPFLAGS integration is gone. From https://www.gnu.org/savannah-checkouts/gnu/make/manual/html_node/Catalogue-of-Rules.html#Catalogue-of-Rules Compiling C programs n.o is made automatically from n.c with a recipe of the form ‘$(CC) $(CPPFLAGS) $(CFLAGS) -c’. Compiling C++ programs n.o is made automatically from n.cc, n.cpp, or n.C with a recipe of the form ‘$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c’. We encourage you to use the suffix ‘.cc’ for C++ source files instead of ‘.C’. Compiling Pascal programs n.o is made automatically from n.p with the recipe ‘$(PC) $(PFLAGS) -c’. Compiling Fortran and Ratfor programs n.o is made automatically from n.r, n.F or n.f by running the Fortran compiler. The precise recipe used is as follows: ‘.f’ ‘$(FC) $(FFLAGS) -c’. ‘.F’ ‘$(FC) $(FFLAGS) $(CPPFLAGS) -c’. ‘.r’ ‘$(FC) $(FFLAGS) $(RFLAGS) -c’. So using CPPFLAGS for C++ sources is the default, not some exotic :) Hopefully this makes the patch integrating CPPFLAGS acceptable. signature.asc Description: Digital signature
Bug#654793: firebird2.5: Hardeneng flags not fully enabled
On 01/11/12 12:23, Damyan Ivanov wrote: -=| Alex Peshkoff, 11.01.2012 11:57:55 +0400 |=- On 01/10/12 21:17, Moritz Muehlenhoff wrote: On Tue, Jan 10, 2012 at 11:06:04AM +0200, Damyan Ivanov wrote: - The check for fortified source functions depends on the use of such functions. If none of them are present the error no protectable libc functions used is shown. However, there are also results that show no (e.g. /usr/bin/fbsvcmgr). As such, there might indeed be a problem with the LDFLAGS being overwritten. Most of the binaries suffer from this, and in the end the reason appears to be missing usage of CPPFLAGS when compiling C++ sources. That's correct. I've meant CPPFLAGS. CPreProcessorFLAGS when compiling C++ resources? I always use for it CXXFLAGS, which are taken into an account in firebird makefiles. http://stackoverflow.com/questions/495598/difference-between-cppflags-and-cxxflags-in-gnu-make CPP can pre-process all kinds of sources, C, C++, Fortran... and we want all of them to have that _FORTIFY_SOURCE=2 define. I think this is the reason to put it in CPPFLAGS -- to have it when pre-processing all source files. As I understand it, CPPFLAGS is now taken into account when compiling plain C sources by pure luck -- the build system relies on the implicit rule for .c - .o compilation in 'make'. And since explicit rules are used for .cpp - .o compilation, CPPFLAGS integration is gone. From https://www.gnu.org/savannah-checkouts/gnu/make/manual/html_node/Catalogue-of-Rules.html#Catalogue-of-Rules Compiling C programs n.o is made automatically from n.c with a recipe of the form ‘$(CC) $(CPPFLAGS) $(CFLAGS) -c’. Compiling C++ programs n.o is made automatically from n.cc, n.cpp, or n.C with a recipe of the form ‘$(CXX) $(CPPFLAGS) $(CXXFLAGS) -c’. We encourage you to use the suffix ‘.cc’ for C++ source files instead of ‘.C’. Compiling Pascal programs n.o is made automatically from n.p with the recipe ‘$(PC) $(PFLAGS) -c’. Compiling Fortran and Ratfor programs n.o is made automatically from n.r, n.F or n.f by running the Fortran compiler. The precise recipe used is as follows: ‘.f’ ‘$(FC) $(FFLAGS) -c’. ‘.F’ ‘$(FC) $(FFLAGS) $(CPPFLAGS) -c’. ‘.r’ ‘$(FC) $(FFLAGS) $(RFLAGS) -c’. So using CPPFLAGS for C++ sources is the default, not some exotic :) Hopefully this makes the patch integrating CPPFLAGS acceptable. Not completely - but now I can see what do you want. I will fix the build. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654793: firebird2.5: Hardeneng flags not fully enabled
-=| Moritz Muehlenhoff, 07.01.2012 14:13:56 +0100 |=- - relro should on yes in all cases. That's the case for the binaries I checked, so all seems fine. Right. - The test for a protected stack cannot show that it's activated if the tested code doesn't use arrays on the stack. Since that's the case for a few binaries I tested everything seems fine. In my tests, I get only one Stack protected: no, not found! and that is for /usr/sbin/fb_inet_server (firebird2.5-classic package). This is one of the simplest binaries, as it contains only one object and a few lines of code, passing control to a shared library it is linked with. This one should be fine indeed. - The check for fortified source functions depends on the use of such functions. If none of them are present the error no protectable libc functions used is shown. However, there are also results that show no (e.g. /usr/bin/fbsvcmgr). As such, there might indeed be a problem with the LDFLAGS being overwritten. Most of the binaries suffer from this, and in the end the reason appears to be missing usage of CPPFLAGS when compiling C++ sources. The following patch seems to fix the problem: === --- a/builds/posix/make.rules +++ b/builds/posix/make.rules @@ -33,7 +33,7 @@ # Please don't use compiler/platform specific flags here - nmcc 02-Nov-2002 WFLAGS:=-I$(SRC_ROOT)/include/gen -I$(SRC_ROOT)/include -I$(SRC_ROOT)/vulcan \ - -DNAMESPACE=Vulcan + $(CPPFLAGS) -DNAMESPACE=Vulcan ifeq ($(STD_ICU),false) WFLAGS:= $(WFLAGS) -I$(ROOT)/extern/icu/source/common -I$(ROOT)/extern/icu/source/i18n === Alex, is this the right place to plug CPPFLAGS? signature.asc Description: Digital signature
Bug#654793: firebird2.5: Hardeneng flags not fully enabled
On Tue, Jan 10, 2012 at 11:06:04AM +0200, Damyan Ivanov wrote: - The check for fortified source functions depends on the use of such functions. If none of them are present the error no protectable libc functions used is shown. However, there are also results that show no (e.g. /usr/bin/fbsvcmgr). As such, there might indeed be a problem with the LDFLAGS being overwritten. Most of the binaries suffer from this, and in the end the reason appears to be missing usage of CPPFLAGS when compiling C++ sources. That's correct. I've meant CPPFLAGS. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654793: firebird2.5: Hardeneng flags not fully enabled
-=| Moritz Muehlenhoff, 05.01.2012 21:46:12 +0100 |=- I'm currently checking all packages, which had a DSA in the last year to enable hardened build flags. firebird2.5 has already been updated to use dpkg-buildflags, but I noticed that not all flags are fully in effect. You can use the hardening-check scripts from the package hardening includes: Out of the three hardening features from the Wheezy default set (protected stack, fortified source and relro) not all are fully applied, e.g. root@pisco:~# hardening-check /usr/sbin/fb_inet_server /usr/sbin/fb_inet_server: Stack protected: no, not found! Fortify Source functions: unknown, no protectable libc functions used Read-only relocations: yes Just to make sure: we are aiming at having yes for these three, right? Does the no protectable libc functions used part mean that this item is OK? The reason is likely that some parts of Firebird build system hardcode specific flags, which nullify the hardened build flags? This is quite possible. I try to patch it already so that it accepts things like optimization flags from the environment, but maybe the linking rules need more work. signature.asc Description: Digital signature
Bug#654793: firebird2.5: Hardeneng flags not fully enabled
On Sat, Jan 07, 2012 at 10:58:31AM +0200, Damyan Ivanov wrote: -=| Moritz Muehlenhoff, 05.01.2012 21:46:12 +0100 |=- I'm currently checking all packages, which had a DSA in the last year to enable hardened build flags. firebird2.5 has already been updated to use dpkg-buildflags, but I noticed that not all flags are fully in effect. You can use the hardening-check scripts from the package hardening includes: Out of the three hardening features from the Wheezy default set (protected stack, fortified source and relro) not all are fully applied, e.g. root@pisco:~# hardening-check /usr/sbin/fb_inet_server /usr/sbin/fb_inet_server: Stack protected: no, not found! Fortify Source functions: unknown, no protectable libc functions used Read-only relocations: yes Just to make sure: we are aiming at having yes for these three, right? Does the no protectable libc functions used part mean that this item is OK? The reason is likely that some parts of Firebird build system hardcode specific flags, which nullify the hardened build flags? This is quite possible. I try to patch it already so that it accepts things like optimization flags from the environment, but maybe the linking rules need more work. - relro should on yes in all cases. That's the case for the binaries I checked, so all seems fine. - The test for a protected stack cannot show that it's activated if the tested code doesn't use arrays on the stack. Since that's the case for a few binaries I tested everything seems fine. - The check for fortified source functions depends on the use of such functions. If none of them are present the error no protectable libc functions used is shown. However, there are also results that show no (e.g. /usr/bin/fbsvcmgr). As such, there might indeed be a problem with the LDFLAGS being overwritten. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
