Hardening options for C and C++ in Slackware

teoberi · 12-15-2023, 06:16 AM

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

Aeterna · 12-15-2023, 06:47 AM

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.

zeebra · 12-15-2023, 07:16 AM

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

teoberi · 12-15-2023, 07:43 AM

Quote:

Originally Posted by zeebra

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

Adding different sets of compilation options seems quite complicated especially since the implementation of these options differs from one package to another and therefore from one developer to another. I'm not saying it doesn't exist, but I haven't studied this aspect. I think Debian has something like that and surely others too.
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.

teoberi · 12-15-2023, 04:08 PM

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"

teoberi · 12-17-2023, 10:10 AM

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

teoberi · 12-17-2023, 10:50 AM

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.

zeebra · 12-17-2023, 11:03 AM

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.

teoberi · 12-17-2023, 11:10 AM

Quote:

Originally Posted by zeebra

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 may be so, without extensive testing we don't know.

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:

Tips and tricks
Disable hardening settings on a per package basis
Warning
This method is not supported by Gentoo and is extremely unlikely to be necessary nowadays. All major distributions ship with PIE by default now.
To disable protections per-package, use C(XX)FLAGS via package.env. Create the file /etc/portage/env/nossp and add to that:

FILE /etc/portage/env/nosspDisable SSP
CFLAGS="${CFLAGS} -fno-stack-protector"
CXXFLAGS="${CXXFLAGS} -fno-stack-protector"
To allow for disabling PIE, create and add to /etc/portage/env/nopie:

FILE /etc/portage/env/nopieDisable PIE
CFLAGS="${CFLAGS} -no-pie"
CXXFLAGS="${CXXFLAGS} -no-pie"
LDFLAGS="${LDFLAGS} -no-pie"
Finally for the package concerned, add either PIE or SSP for to /etc/portage/package.env and the relevant /etc/portage/env/<filename>, for this example sys-libs/zlib is used here:

FILE /etc/portage/package.envDisable PIE for sys-libs/zlib
sys-libs/zlib nopie

zeebra · 12-17-2023, 11:15 AM

Quote:

Originally Posted by teoberi

It may be so, without extensive testing we don't know.

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

Then perhaps give it a test spin on an available machine or VM with Slackware-source and "make_world.sh". Should be a fun experiment at least.

teoberi · 12-17-2023, 11:27 AM

Quote:

Originally Posted by zeebra

Then perhaps give it a test spin on an available machine or VM with Slackware-source and "make_world.sh". Should be a fun experiment at least.

Yes, it would be something interesting but certainly very time-consuming both in the physical or virtual machine.
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.

teoberi · 12-18-2023, 02:16 AM

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:

Lack of Support for CPPFLAGS Environment Variable
CMake does not support the CPPFLAGS environment variable. This variable contains C/C++ preprocessor flags (options) that are passed to the compiler at compile time and is defined in the makepkg configuration file. Because CMake does not support it, all flags defined in this variable will not be passed to the compiler.

Currently, CPPFLAGS contains only the -D_FORTIFY_SOURCE=2 flag. This is a hardening flag and is important for security reasons, as it can avoid specific types of attacks that can take place in exploitable buffer overflows. For more details about this flag please see feature_test_macros(7).

The CMake developers are aware of this situation, since there is an old issue12 opened (back in 2012) at the CMake bug tracker about it, and it is still not solved. While this is not solved, packagers should manually handle the pass of CPPFLAGS to CMake at packaging level.

A solution similar to the one in the Postfix case where I added all the flags from CPPFLAGS, CFLAGS, CXXFLAGS and LDFLAGS to CCARGS.

teoberi · 12-20-2023, 07:03 AM

Quote:

Originally Posted by teoberi

This is the end of my experiment of using hardening options for packages compiled from sources.
...
Once this stage is finished, I am thinking about the following stages:
...
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.

Applying these hardening options for the original Slackware packages seems a bit problematic at first try (at least in the case of bind, for which I opened a separate thread).
In this case, the correct solution would be to compile at source with these options, recompiling means twice the work.

teoberi · 12-22-2023, 01:43 AM

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/

Petri Kaukasoina · 12-22-2023, 04:17 AM

Quote:

Originally Posted by teoberi

RPATH and RUNPATH, which are generally recommended not to be used

There is nothing wrong in using RPATH or RUNPATH if they point to system directories that are only writable by root. But it's dangerous if they point to /tmp. Anyone could plant a malicious library under /tmp. Check and remove with this script:

Code:

#!/bin/sh
# remove_tmp_rpath
# To really do it, run as 'DOIT=YES ./remove_tmp_rpath'
# pk 2023-12-22

DOIT=${DOIT:-NO}

if [ "$(/bin/id -u)" != 0 ]; then
  echo 'Run as root.'
  exit 1
fi

cd /var/adm/packages
for pkg in *; do
( cd /
  while read line; do
    [ "$line" = "FILE LIST:" ] && break
  done
  while read f; do
    [ -x "$f" -a -f "$f" -a -r "$f" ] && \
      objdump -p "$f" 2>/dev/null | \
      grep -q R.*PATH.*/tmp && {
        echo A dangerous value of RPATH/RUNPATH:
        echo Package: "$pkg"
        echo File: "/$f"
        objdump -p "$f" | grep R.*PATH
        if [ "$DOIT" = "YES" ]; then
          patchelf --remove-rpath "/$f"
          echo Removed.
        else
          echo Would remove.
        fi
        echo
      }
  done 
) < $pkg
done