Hardening options for C and C++ in Slackware

teoberi · 12-11-2023, 04:44 AM

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.

zeebra · 12-11-2023, 06:16 AM

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?

teoberi · 12-11-2023, 06:48 AM

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:

Code:

checksec --file=/usr/sbin/named

Code:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
Partial RELRO   No canary found   NX enabled    No PIE          No RPATH   No RUNPATH   No Symbols        Yes   5               13              /usr/sbin/named

Code:

checksec --file=/usr/sbin/httpd

Code:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
Partial RELRO   No canary found   NX enabled    PIE enabled     RW-RPATH   No RUNPATH   No Symbols        No    0               10              /usr/sbin/httpd

I also found a package that is OK, ssh

Code:

checksec --file=/usr/bin/ssh

Code:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   No Symbols        Yes   10              19              /usr/bin/ssh

The packages to which I added the respective options during build also look the same:

Code:

checksec --file=/usr/bin/7zz

Code:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   No Symbols        Yes   3               12              /usr/bin/7zz

Code:

checksec --file=/usr/local/squid/sbin/squid

Code:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   No Symbols        Yes   11              25              /usr/local/squid/sbin/squid

GazL · 12-11-2023, 10:53 AM

Quote:

CFLAGS="-fPIE -fstack-protector-strong"

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.

henca · 12-11-2023, 12:40 PM

Quote:

Originally Posted by teoberi

I wonder if Slackware should do something for the core packages

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

teoberi · 12-12-2023, 02:28 AM

Quote:

Originally Posted by GazL

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.

Agree with you about -fPIC or -fPIE.

Quote:

When compiling code in any of the situations in the below table, add the corresponding additional options:

When Additional options flags
for executables -fPIE -pie
for shared libraries -fPIC -shared

Quote:

For building shared objects, you must compile with -fPIC in (CFLAGS or CXXFLAGS) and link with -shared (in LDFLAGS).

An error usually occurs if you force the wrong flag.
https://www.mjr19.org.uk/IT/pic_pie.html

Quote:

/usr/bin/ld: libfoo.a(bar.o): relocation R_X86_64_32 against `baz' can not be used when making a PIE object; recompile with -fPIC

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

jmccue · 12-12-2023, 11:08 AM

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.

teoberi · 12-12-2023, 01:08 PM

Quote:

Originally Posted by jmccue

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.

teoberi · 12-12-2023, 01:49 PM

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

Quote:

lzop configuration summary
--------------------------
lzop version : 1.04
configured for host : x86_64-slackware-linux-gnu
source code location : .
compiler : gcc
preprocessor definitions : -DLZOP_HAVE_CONFIG_H=1
preprocessor flags : -O2 -D_FORTIFY_SOURCE=2
compiler flags : -fPIE -fstack-protector-strong
linker flags : -Wl,-pie,-z,now,-s
link libraries : -llzo2

lzop 1.04 configured.

teoberi · 12-13-2023, 06:48 AM

The situation in the case of PHP:
Slackware (without hardening options)

Code:

checksec --file=/usr/local/bin/php

Code:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
Partial RELRO   No canary found   NX enabled    No PIE          RW-RPATH   No RUNPATH   22307 Symbols     No    0               29              /usr/local/bin/php

Code:

checksec --file=/usr/lib64/httpd/modules/libphp.so

Code:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
Partial RELRO   No canary found   NX enabled    DSO             RW-RPATH   No RUNPATH   22245 Symbols     No    0               29              /usr/lib64/httpd/modules/libphp.so

Ubuntu (default)

Code:

checksec --file=php-fpm8.1-ubuntu

Code:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   No Symbols        Yes   15              33              php-fpm8.1-ubuntu

Code:

checksec --file=libphp8.1.so-ubuntu

Code:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
Full RELRO      Canary found      NX enabled    DSO             No RPATH   No RUNPATH   No Symbols        Yes   12              30              libphp8.1.so-ubuntu

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:

Code:

checksec --file=/usr/local/bin/php

Code:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   No Symbols        Yes   15              36              /usr/local/bin/php

Code:

checksec --file=/usr/lib64/httpd/modules/libphp.so

Code:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
Full RELRO      Canary found      NX enabled    DSO             No RPATH   No RUNPATH   No Symbols        Yes   14              35              /usr/lib64/httpd/modules/libphp.so

Aeterna · 12-13-2023, 07:46 AM

Quote:

Originally Posted by teoberi

The situation in the case of PHP:
Slackware

Code:

checksec --file=/usr/local/bin/php

Code:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
Partial RELRO   No canary found   NX enabled    No PIE          RW-RPATH   No RUNPATH   22307 Symbols     No    0               29              /usr/local/bin/php

Code:

checksec --file=/usr/lib64/httpd/modules/libphp.so

Code:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
Partial RELRO   No canary found   NX enabled    DSO             RW-RPATH   No RUNPATH   22245 Symbols     No    0               29              /usr/lib64/httpd/modules/libphp.so

Ubuntu

Code:

checksec --file=php-fpm8.1-ubuntu

Code:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   No Symbols        Yes   15              33              php-fpm8.1-ubuntu

Code:

checksec --file=libphp8.1.so-ubuntu

Code:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
Full RELRO      Canary found      NX enabled    DSO             No RPATH   No RUNPATH   No Symbols        Yes   12              30              libphp8.1.so-ubuntu

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

teoberi · 12-13-2023, 12:54 PM

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

Aeterna · 12-13-2023, 07:25 PM

beginning with GCC 14, new option is going to be introduced

Quote:

-fhardened

https://www.phoronix.com/news/GCC-fh...rdening-Option
which will cover:

Quote:

-D_FORTIFY_SOURCE=3 (or =2 for older glibcs)
-D_GLIBCXX_ASSERTIONS
-ftrivial-auto-var-init=pattern
-fPIE -pie -Wl,-z,relro,-z,now
-fstack-protector-strong
-fstack-clash-protection
-fcf-protection=full (x86 GNU/Linux only)

teoberi · 12-14-2023, 12:06 AM

Quote:

Originally Posted by Aeterna

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:

Quote:

SLKCFLAGS="-O2 -fPIC"
LIBDIRSUFFIX="64"

Code:

checksec --file=/usr/bin/ssh

Code:

RELRO           STACK CANARY      NX            PIE             RPATH      RUNPATH      Symbols         FORTIFY Fortified       Fortifiable     FILE
Full RELRO      Canary found      NX enabled    PIE enabled     No RPATH   No RUNPATH   No Symbols        Yes   10              19              /usr/bin/ssh

teoberi · 12-14-2023, 07:42 AM

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