GCC Preparing To Introduce "-fhardened" Security Hardening Option

[writequit]

it will take a decade or two before debian would include it in its packages :E

apt-cache policy gcc
gcc:
Installed: 4:13.2.0-1
Candidate: 4:13.2.0-1
Version table:
*** 4:13.2.0-1 500
500 http://deb.debian.org/debian unstable/main amd64 Packages
500 http://deb.debian.org/debian testing/main amd64 Packages

[svillemot]

it will take a decade or two before debian would include it in its packages :E

$ dpkg-buildflags
ASFLAGS=
CFLAGS=-g -O2 -ffile-prefix-map=/buildd=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2
CXXFLAGS=-g -O2 -ffile-prefix-map=/buildd=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
DFLAGS=-frelease
FCFLAGS=-g -O2 -ffile-prefix-map=/buildd=. -fstack-protector-strong -fstack-clash-protection -fcf-protection
FFLAGS=-g -O2 -ffile-prefix-map=/buildd=. -fstack-protector-strong -fstack-clash-protection -fcf-protection
GCJFLAGS=-g -O2 -ffile-prefix-map=/buildd=. -fstack-protector-strong -fstack-clash-protection -fcf-protection
LDFLAGS=-Wl,-z,relro
OBJCFLAGS=-g -O2 -ffile-prefix-map=/buildd=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
OBJCXXFLAGS=-g -O2 -ffile-prefix-map=/buildd=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection

So as you can see, Debian already uses several of those hardening options by default.

[RealNC]

I guess this is for people who build GCC themselves? AFAICT, distro-provided GCC builds already enable hardening options by default.

[Weasel]

$ dpkg-buildflags
ASFLAGS=
CFLAGS=-g -O2 -ffile-prefix-map=/buildd=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2
CXXFLAGS=-g -O2 -ffile-prefix-map=/buildd=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
DFLAGS=-frelease
FCFLAGS=-g -O2 -ffile-prefix-map=/buildd=. -fstack-protector-strong -fstack-clash-protection -fcf-protection
FFLAGS=-g -O2 -ffile-prefix-map=/buildd=. -fstack-protector-strong -fstack-clash-protection -fcf-protection
GCJFLAGS=-g -O2 -ffile-prefix-map=/buildd=. -fstack-protector-strong -fstack-clash-protection -fcf-protection
LDFLAGS=-Wl,-z,relro
OBJCFLAGS=-g -O2 -ffile-prefix-map=/buildd=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
OBJCXXFLAGS=-g -O2 -ffile-prefix-map=/buildd=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection

So as you can see, Debian already uses several of those hardening options by default.

Yuck.

[CochainComplex]

Surprisingly, clear Linux uses a lot of the hardening flags. Some almost even everywhere like fstack-protector-strong ..afaik also the DFortify thing too.

[carewolf]

certainly an improvement than having people look up all those settings, but would be better just to make it the default. it's not like linux makes mitigations=off the default, why should the "should be always safe and make more secure code" compiler options be default off?

Because this for incorrect code. If mitigations=off was only to mitigate errors in the kernel, it wouldn't be on by default.

[oleid]

Yuck.

Why yuck?

[Weasel]

Why yuck?

It adds unnecessary bloat and overhead everywhere, when the correct "security fix" (note I'm not going to say "fix the code", even though that's actually the true proper way, we can't have it perfect) is to simply run untrusted apps as separate user or sandbox without ability to screw you over, because you should do that regardless of these crap flags or not.

It's absurd to have every single app (and libraries it depends on) have this junk in it, even if the app is completely trustworthy. And if you download "malicious" files using special crafts to trigger bugs in your trusted app, sounds like skill issue to me for not verifying it first (e.g. on browser, which is supposed to be sandboxed).

I fucking hate it so much that I'm considering Gentoo for the first time now.

[coder]

It adds unnecessary bloat and overhead everywhere, when the correct "security fix" (note I'm not going to say "fix the code", even though that's actually the true proper way, we can't have it perfect) is to simply run untrusted apps as separate user or sandbox without ability to screw you over, because you should do that regardless of these crap flags or not.

Following this mindset, we shouldn't have libraries, because you don't want to mix secure and insecure ones in the same executable. So, instead of libraries, we can make every one of them a microservice and pass messages instead of direct function calls. Then, your 16-core, 5 GHz PC can perform like a dual-CPU, 500 MHz machine from 1999.

Containers are a useful, but entirely insufficient solution to security problems.

[Weasel]

Following this mindset, we shouldn't have libraries, because you don't want to mix secure and insecure ones in the same executable. So, instead of libraries, we can make every one of them a microservice and pass messages instead of direct function calls. Then, your 16-core, 5 GHz PC can perform like a dual-CPU, 500 MHz machine from 1999.

Containers are a useful, but entirely insufficient solution to security problems.

Libraries run in the context of the app. If the library is insecure then simply don't use it. It's no different than bringing flawed code in your app in the first place with a static library or just copy-pasted code from the library. Why do people think libraries are any different?

I also don't think we have similar terms for "trusting" an app. By "trust" I don't mean reviewing all the code. But applications for example that have access to the internet are, by default, untrusted (very few exceptions like system updater, I guess). You don't have to verify the libraries it uses to know this.

There can be a flaw in the app or a flaw in the library, it doesn't matter. In the end, it's a flaw in the "process" that has access to the internet. Same privileges, and memory map and so on.