Dovecot (like PostgreSQL), it is quite well built by default, the only changes are:
LDFLAGS="-Wl,-s,--enable-new-dtags" -s -> strip binary --enable-new-dtags -> change RPATH with RUNPATH |
I would suggest hardened malloc also please look at hardened Gentoo. I never had any problems with hardened Gentoo. Also some things worth checking out you can find at HardenedBSD site. In general you will almost need separate version of Slackware I doubt that this is feasible.
|
It seems like, if you want to use compiler hardening functions, and want your software to build/work, you have to do it on a case to case basis, rather than as a general rule, no?
In that case, it would be better to add compile time options in Slackbuild scripts, rather than to change compiler defaults. Or add a set of different variations/rules and #include these in Slackbuild scripts on a case to case basis.. |
Quote:
Compiling GCC by default with some of these hardening options would be a more elegant solution, but this also requires testing. The simplest solution is to add these options to the compilation from sources/SlackBuilds, but this also requires testing/studying the configure/Makefile files and of course the installation instructions. I say that there is still a lot of work to standardize approaches in this case. |
Postfix (without dynamically-linked library support).
Here the compilation is a bit different.:) From here (section 4.3 - Building with Postfix position-independent executables (Postfix ≥ 3.0)) To make makefiles command is added: pie=yes The other options are chosen (section 4.7 - Overriding other compile-time features) To make makefiles command is added: OPT="-O2" To CCARGS is added: "-Wl,-z,now,-s -fstack-protector-strong -D_FORTIFY_SOURCE=2" |
Network UPS Tools (NUT)
CPPFLAGS="-O2 -D_FORTIFY_SOURCE=2" CFLAGS="-fPIC -pie -fstack-protector-strong" CXXFLAGS="-fPIC -pie -fstack-protector-strong" LDFLAGS="-Wl,-z,now,-s" A slightly different configuration from the previous ones in the case of pie. Maybe because of the different GCC standards used in the Makefile (-std=gnu99, -std=gnu++11). |
This is the end of my experiment of using hardening options for packages compiled from sources.
The packages compiled in this way were: 1. 7-Zip (manual compilation from sources); 2. DCC (Distributed Checksum Clearinghouses); 3. pax (build from SlackBuilds); 4. lzop (compile from SlackBuilds); 5. PHP (manual compilation from sources); 6. PostgreSQL (manual compilation from sources); 7. Dovecot (manual compilation from sources); 8. Postfix (manual compilation from sources); 9. Network UPS Tools (NUT) (manual compilation from sources); 10. Squid (manual compilation from sources). After this exercise I could conclude: 1. some of these options could be enabled by default by the proper compilation of the compiler; Examples: GCC 13 --enable-default-pie and --enable-default-ssp GCC 14 -hardened 2. the following options were used in almost every package CPPFLAGS="-O2 -D_FORTIFY_SOURCE=2" CFLAGS="-fstack-protector-strong" CXXFLAGS="-fstack-protector-strong" LDFLAGS="-Wl,-z,now,-s" 3. some packages implement configuration options for some of these options Examples: --with-pic (does not always work and then the respective flag must be added) --disable-rpath pie=yes 4. not all packages properly implement separate options for executables and shared libraries 5. I tested all these changes for each package compiled in this way using the checksec utility (from Github with all pull requests accepted) and comparing my results with those of Ubuntu and Fedora (Fedora seems to me to compile packages more strictly than Ubuntu from the point of view of checksec). Once this stage is finished, I am thinking about the following stages: 1. compiling Clamav with these options (uses CMake, which I still have to learn about); 2. to apply these options also for the Slackware packages (which are part of the basic distribution, for example httpd, bind, etc.) that implement services used on my servers. |
Not sure "1." is a proper compilation of the compiler for packages that are suppose to build and generally work as intended across a large range of use cases. It might not even be the proper option for a specific use case, on a single computer. It's probably a better approach to do this on a case to case basis in the buildscripts, rather than as a default, which would be somewhat similar to Gentoo, no? Not sure even hardened Gentoo sets these things as defaults in the compiler.
It could be possible to test this just for fun with "make_world.sh". But heck, you'd need to change all the compilers. |
Quote:
However, I have also seen theories that support the application of these options to the compiler and their deactivation in specific cases where they do not work. https://wiki.gentoo.org/wiki/Hardened_Gentoo Quote:
|
Quote:
|
Quote:
Unfortunately, I don't have (now) neither the time nor the hardware for such a thing. Time is a luxury now (I'm very busy at my basic job) so all I can do is take it on individually chosen packages during breaks. So maybe I will reach a result if it is possible or not.:) For my basic job, Slackware is my choice (I could have used Ubuntu, Debian even Fedora considering that I started in the Linux world with Red Hat as long as it was free of charge) but also my responsibility, if something happens I am the only culprit. |
Clamav (with CMake)
It was quite easy until the end and I learned a lot.:) -D CMAKE_C_FLAGS="-O2 -D_FORTIFY_SOURCE=2 -fPIC -fstack-protector-strong" -D CMAKE_CXX_FLAGS="-O2 -D_FORTIFY_SOURCE=2 -fPIC -fstack-protector-strong" -D CMAKE_EXE_LINKER_FLAGS="-Wl,-pie,-z,now,-s" -D CMAKE_SHARED_LINKER_FLAGS="-Wl,-shared,-z,now,-s" -D CMAKE_SKIP_RPATH=ON The only problem that has arisen is related to the fact that CMake does not yet have support for CPPFLAGS. The friends at ArchLinux used the solution of adding the flags from CPPFLAGS to CFLAGS and CXXFLAGS. https://wiki.archlinux.org/title/Use...age_guidelines Quote:
|
Quote:
In this case, the correct solution would be to compile at source with these options, recompiling means twice the work. |
A few more useful observations:
1. some packages (depending on the compilation standard used or C/C++) do not accept the "-pie" flag in LDFLAGS (linking error), the solution is to add it to CFLAGS and CPPFLAGS. Examples bind, Network UPS Tools (NUT); 2. binary stripping can be done during compilation (LFDLAGS="-Wl,-s") or using the strip command on already generated executables. It seems that the first option is recommended. I have not met cases in which it is not possible; https://www.baeldung.com/linux/strip-executables 3. the most problematic verification in checksec is RPATH and RUNPATH, which are generally recommended not to be used (Fedora does this for all the packages I checked). If it is still needed, RUNPATH is recommended, which can be obtained by adding in LDFLAGS="-Wl,--enable-new-dtags" https://blog.tremily.us/posts/rpath/ |
Quote:
Code:
#!/bin/sh |
All times are GMT -5. The time now is 08:57 PM. |