Hardening options for C and C++ in Slackware
 

I started documenting myself about this topic some time ago when I was trying to compile the 7-Zip archiver from sources. I got the first information about these compilation options from Arch Linux and OpenSUSE. Then I started to study how this is done in other distributions, i.e. Debian, Ubuntu, Fedora, OpenSUSE, Gentoo.
I found the document here which is quite clear and has references to the documentation of the distributions mentioned above.
In the case of Slackware, the SlackBuilds have the SLKCFLAGS variable that contains the "-O2" option plus a few more (depends on the package) and which is then transferred to CFLAGS in the configuration stage.
Macros (variables) CPPFLAGS, CXXFLAGS, LDFLAGS do not appear.
I found somewhere that these options would be of less importance for home users (if they don't care about the security of their operating system) but they are important for servers.
Is there interest in this in Slackware?
I am in the process of securing the packages compiled by me (and they are not few, I compile from sources even some packages that already exist in Slackware but not in the configuration I need).
Now I use the following macros in the configuration stage:
CPPFLAGS="-O2 -D_FORTIFY_SOURCE=2"
CFLAGS="-fPIE -fstack-protector-strong"
CXXFLAGS="-fPIE -fstack-protector-strong"
LDFLAGS="-Wl,-pie,-z,now,-s"
I built the packages from sources like this:
7-Zip;
DCC (Distributed Checksum Clearinghouses);
and
Squid.
Testing the application of these options is done with the utility here.

All Slackware sources are available with the buildscripts and any other related files. Surely, it would be easiest/best to replicate these builds as closely as possible by building the packages in the same way and adding your own customization?

I do this for packages compiled by me from sources.
I only use the Slackware skeleton, I compile the rest of the packages and apply these options.
I wonder if Slackware should do something for the core packages (those not modified by system administrator).
I ask this because I change for nothing the packages I use if the base remains unchanged. I don't have the necessary infrastructure to recompile the entire Slackware base.
Some examples:
I also found a package that is OK, ssh:)
The packages to which I added the respective options during build also look the same:

As I understand it, -FPIC and -FPIE are very similar, but -FPIE takes a few shortcuts because it doesn't have to worry about the generated code being put in shared libraries. Objects intended to go in shared library really should be built with -fPIC. Changing the global CFLAGS to -fPIE might have unintended consequences.

By all means use -pie if you want — though a lot of the time I think it's just security theatre and most things don't need this extra protection — but I'd suggest you stick with -fPIC unless you know the objects built won't be used in a library.

Basically the -fstack-protector-strong option will give you some extra protection against buffer overflows at the cost of some performance. Most people will probably prefer performance.

If you really want to search for problems like that, you might want to try -fsanitize=address together with -g which will give you more details about the memory problem than to just exit with an error code. However, again, this is at a (probably even bigger) performance cost.

If some program that you have compiled with -fstack-protector-strong bails out with a warning/error you might want to track the problem down with -fsanitize=address or some separate tool like valgrind. If you been running with programs compiled with -fstack-protector-strong for some years and never seen any warning/error you might have wasted some performance, but at least you could feel a bit safer.

regards Henrik

Agree with you about -fPIC or -fPIE.
An error usually occurs if you force the wrong flag.
https://www.mjr19.org.uk/IT/pic_pie.html
You can differentiate an ELF executable from a shared library using the utilities:
1. file
https://www.cybertuna.net/position-i...-and-aslr.html
2. readelf
https://serializethoughts.com/2019/06/29/elf-pic-pie
I do not change the compilation options without first documenting what it is about and analyzing the binaries/shared libraries from at least 2 important distributions, i.e. Ubuntu and Fedora.

PIE implementation:
https://isopenbsdsecu.re/mitigations/pie/

In the case of 7-Zip:
-fPIC is defined in CFLAGS (compiler options) in the .mak file, so -fPIE is no longer necessary;
-pie has been added to LDFLAGS (link options).

You may get more informed responses in LQ Programming Forum :)

But very nice link and I will use those guidelines for things I write. But for me, I just keep what the developer decided to use in their projects, especially when it comes to '-O?'. Some optimization levels have been known to introduce runtime issues. For my objects I use -O1, but as you suggested I heard -O2 has no issues either.

But I will keep an eye on your document.

Most official Slackware slackbuilds use O2.
In the case of CPPFLAGS it is a requirement for -D_FORTIFY_SOURCE=2
I opened this topic to signal the fact that other distributions use these hardening options.
Even the GNU GCC compiler can be compiled with:
--enable-default-pie
and
--enable-default-ssp
to enable these options by default.
The PIE implementation stage from a previous post indicates default use by Gentoo, Alpine Linux, Fedora, RHEL, Open BSD, Apple, Android.

An example configuration for the lzop package using a modified SlackBuilds with the options from post 1 applied.

The situation in the case of PHP:
Slackware (without hardening options)
Ubuntu (default)
After the changes below
CPPFLAGS="-O2 -D_FORTIFY_SOURCE=2"
CFLAGS="-fstack-protector-strong"
CXXFLAGS="-fstack-protector-strong"
LDFLAGS="-Wl,-z,now,-s"
EXTRA_LDFLAGS_PROGRAM="-Wl,-pie"
and adding options:
--disable-rpath
--with-pic
Now I have:

How much (in your opinion) canary affects hardening options?

RELRO, STACK CANARY, PIE, FORTIFY differ from what Ubuntu has in the case of PHP.
Canary is one of the recommended hardening options in the document here and the list of contributors is impressive.
I don't think I should bother myself if they proposed this.
Other explanations:
https://lwn.net/Articles/584225/
If Linus Torvalds also hit his head with this, it means that it is still something.:)
https://www.redhat.com/en/blog/secur...-fortifysource

beginning with GCC 14, new option is going to be introduced
https://www.phoronix.com/news/GCC-fh...rdening-Option
which will cover:

In this case, it seems that we are not yet ready compared to other distributions.
We will need a mass rebuild and a lot of work.:)
Some argue not to modify the compilation options that the packages come with by default, but the truth is that not all developers deal with these options, others leave it to the distribution maintainers.
An example where the developers have taken care of this is ssh, although the Slackware SlackBuild only contains the options:

For PostgreSQL
CPPFLAGS="-O2 -D_FORTIFY_SOURCE=2"
CFLAGS="-fPIC -fstack-protector-strong"
CXXFLAGS="-fPIC -fstack-protector-strong"
LDFLAGS="-Wl,-z,now,-s"
LDFLAGS_EX="-Wl,-pie"
LDFLAGS_SL="-Wl,-shared"
and adding option:
--disable-rpath
As an observation, the configuration in PostreSQL is very well done with the possibility to set:
LDFLAGS_EX="-Wl,-pie" -> for executables
LDFLAGS_SL="-Wl,-shared" -> for shared libraries