SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Observation CXXFLAGS does not appear anywhere in the documentation or in the command output:
Code:
./configure --help
Quote:
Some influential environment variables:
CC C compiler command
CFLAGS C compiler flags
LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a
nonstandard directory <lib dir>
LIBS libraries to pass to the linker, e.g. -l<library>
CPPFLAGS (Objective) C/C++ preprocessor flags, e.g. -I<include dir> if
you have headers in a nonstandard directory <include dir>
CPP C preprocessor
Use these variables to override the choices made by `configure' or to help
it to find libraries and programs with nonstandard names/locations.
It can be built without it.
Code:
checksec --file=/usr/sbin/iucode_tool
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 2 7 /usr/sbin/iucode_tool
What's the point of hardening every executable in the distribution? I can see that those that run as root or that get arbitrary input from the network could use hardening, but the vast majority of executables just run under the user's identity. I don't think that stack smashing the latter would get you any special privileges.
Simple, as in real life, everything depends on the chosen security options.
At home, you can opt for the installation of a security system for the whole house, only for certain parts or not at all.
In the business environment, I don't think you can afford to neglect security.
Analogy:
home = home PC
business = business workstation/server
In the first post of this thread, there is a link to a document related to this aspect made by representatives from Ericsson, Intel, Linux Foundation, IBM, Micro$oft, Google, Canonical (Ubuntu), RHEL, etc in section 7. Contributors. Also, section 10. References is quite extensive.
The GNU Compiler Collection (GCC) has specific options for these hardening flags which, if enabled when compiling the compiler, become default when using the compiler executable thus generated (section 2.2. What should you do when compiling compilers?).
In section 3. Recommended Compiler Options there are links related to this topic from major Linux distributions such as Debian, Gentoo, Fedora, OpenSUSE and Ubuntu.
If we were discussing how difficult it would be to do this with the two possible solutions:
1. compiling the compiler with these options to become default (there will be cases of packages that do not compile and will have to be modified manually);
2. compiling each package with manual setting of these flags.
Both variants require a lot of effort and a lot of testing, but other distributions have already done it. Even for distributions that have package maintainers (e.g. Debian) this took quite a long time but it was done.
Simple, as in real life, everything depends on the chosen security options.
At home, you can opt for the installation of a security system for the whole house, only for certain parts or not at all.
In the business environment, I don't think you can afford to neglect security.
Analogy:
home = home PC
business = business workstation/server
In the first post of this thread, there is a link to a document related to this aspect made by representatives from Ericsson, Intel, Linux Foundation, IBM, Micro$oft, Google, Canonical (Ubuntu), RHEL, etc in section 7. Contributors. Also, section 10. References is quite extensive.
The GNU Compiler Collection (GCC) has specific options for these hardening flags which, if enabled when compiling the compiler, become default when using the compiler executable thus generated (section 2.2. What should you do when compiling compilers?).
In section 3. Recommended Compiler Options there are links related to this topic from major Linux distributions such as Debian, Gentoo, Fedora, OpenSUSE and Ubuntu.
If we were discussing how difficult it would be to do this with the two possible solutions:
1. compiling the compiler with these options to become default (there will be cases of packages that do not compile and will have to be modified manually);
2. compiling each package with manual setting of these flags.
Both variants require a lot of effort and a lot of testing, but other distributions have already done it. Even for distributions that have package maintainers (e.g. Debian) this took quite a long time but it was done.
Yes, and it is highly recommended for test compilation.
An example for Clamav on my last Pull Request. https://github.com/Cisco-Talos/clama...cks#step:9:240
In the document from the first post of this thread it appears:
Quote:
_FORTIFY_SOURCE is recommended for all applications that depend on glibc and should be widely deployed. Most packages in all major Linux distributions enable at least _FORTIFY_SOURCE=2 and some even enable _FORTIFY_SOURCE=3.
There has been some discussion in this thread about using these hardening options.
I found in the previous link the reference to: https://github.com/jvoisin/compiler-flags-distro
The respective document presents the status of the implementation of these options for several distributions of Linux, Android and Google Chrome.
It is a bit difficult to read the document because of the scroll bars, but I am attaching it in Adobe Acrobat Reader format.
Remarks
1. Stack canary "-fstack-protector" (-fstack-protector!=-fstack-protector-strong) can be enabled by default through the "--enable-stack-protector" configuration option, but only for *-efi architectures by modifying grub.SlackBuild, something already done by Didier Spaier here.
2. Build as position-independent code (-fPIE -pie) is disabled by the GRUB maintainers in the configure.ac file, but Fedora and Ubuntu (as examples) have changed this.
Code:
checksec --file=usr/sbin/grub2-install-fedora
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 No 0 19 usr/sbin/grub2-install-fedora
Code:
checksec --file=/tmp/2/grub-probe-fedora
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 8 24 /tmp/2/grub-probe-fedora
Code:
checksec --file=/tmp/2/grub-probe-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 8 24 /tmp/2/grub-probe-ubuntu
I updated GRUB 2.06 to 2.12 in VirtualBox with the hardening options above and it works.
I will test the configuration for a few days and then when GRUB comes out of "testing" I will apply it to the production servers.
Last edited by teoberi; 01-02-2024 at 09:37 AM.
Reason: Correction
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.