5 ms·

last time I checked the Debian and Gentoo hardening guides relro/pie were standard practice. I can't remember the time we didn't use it and I've been around for

last time I checked the Debian and Gentoo hardening guides relro/pie were standard practice. I can't remember the time we didn't use it and I've been around for a minute. this is my template for most Linux projects (except when "something else" is needed :)) ... please don't copy paste without certainty of what it does: CFLAGS_BASE := -c -O2 -Wall -Werror -Wpedantic -pipe $(CFLAGS) CFLAGS_HARD := -fPIE -Wformat-security -fstack-protector-strong --param=ssp-buffer-size=4 -fcf-protection -Wimplicit-fallthrough -D_FORTIFY_SOURCE=2 CFLAGS_DEBUG := -g3 -gdwarf-2 CFLAGS_RELEASE := -s -fomit-frame-pointer -march=native LDFLAGS := -Wl,-z,now -Wl,-z,relro -Wl,-z,defs -Wl,-pie -Wl,--no-copy-dt-needed-entries LDFLAGS_HMALLOC := -L/usr/local/lib -lhardened_malloc # see https://github.com/GrapheneOS/hardened_malloc don't get security advise from random strangers like me on HN, also don't forget to always ship code with an apparmor profile and lock down the systemd unit file with seccomp filters and other hardening options (even RH is just another IBM company now, they have excellent docs on this and some impressive appsec/security people on their payroll https://www.redhat.com/sysadmin/mastering-systemd https://www.redhat.com/sysadmin/mastering-systemd). Also after learning about systemd hardening this was the time I stopped worrying and learned to love systemd. (actually just joking I still hate systemd with a passion)

loeg 5y ago
Isn’t -gdwarf-2 an odd choice? Wouldn’t you prefer one of the newer, more expressive flavors of DWARF? -g by itself gets you the default, which is newer than 2 (at least for clang).
secondcoming 5y ago
Wouldn't some of this be mitigated by specifying function visiblity? AIUI, when building a shared lib, all functions are visible in case a user wants to hook any functions via, e.g. LD_PRELOAD
- Seirdy 5y ago
  Yes, fvisibility=hidden is a great addition; combined with LTO and a Clang toolchain, you can also add fsanitize=cfi. The CFI sanitizer adds a 1% perf penalty for a significant exploit mitigation. It complements -fcf-protection=full nicely. You can also add fsanitize=shadow-stack (ARM) or fsanitize=safe-stack (x86_64) for stronger protection than -fstack-protector-all. This will cause many programs to crash.
  - DyslexicAtheist 5y ago
    much appreciated thanks!!
    - Seirdy 5y ago
      Also you should skip ssp-buffer-size since fstack-protector-strong (let alone fstack-protector-all) should protect stacks regardless.
gavinray 5y ago
... please don't copy paste without certainty of what it does Would you be willing to explain why this specific set of flags (I realize I could google them all, but I also realize that some flags have interactions with other flags and trying to find those is not straightforward)? Genuinely interested, not holding you accountable for my computer exploding.
- yjftsjthsd-h 5y ago
  If nothing else, I'd like to call out -Werror as a footgun when shipping for other people to use. By all means use it for dev work when you control the environment, but as an end-user (well, downstream, at least) it's a problem when packages outright break because I'm building with a newer compiler version that added more warnings.
  - DyslexicAtheist 5y ago
    absolutely. you don't want to have -Werror in a fast moving FOSS project. It depends on what you're doing. I compile against latest compiler versions in a CI pipeline that I want to fail. It's probably not how you want to ship in FOSS projects.
- jcranmer 5y ago
  Not OP, but here goes: * -fPIE : Compile as a 'position-independent executable'. This allows code and data sections of the executable to be installed at random locations in the address space, and comes with a mild cost due to needing extra indirections to handle position-independent code. * -Wformat-security: adds some extra warnings around possible misuse of printf and scanf. * -fstack-protector-strong --param=ssp-buffer-size=4: adds extra code in functions to check that stack buffer overflows likely haven't occurred. The second bit does it for every variable at least 4 bytes in size. * -fcf-protection: this enables Intel CET instructions to check control flow integrity. This essentially causes the hardware to have a shadow stack and other tracking bits to prevent ROP attacks from occurring, but it does require very new hardware to work correctly. * -Wimplicit-fallthrough: warns if switch cases don't have breaks. * -D_FORTIFY_SOURCE=2: this causes several basic C functions (such as memcpy) in glibc to compile in a somewhat more secure manner, namely aborting the program if it can detect that it's going to overflow the bounds of an object. The '2' level adds extra checks that prohibits some legal C behavior (for example, buffer overflows that run into a different subobject of the same object). * -s: Strip the resulting binary after linking. * -fomit-frame-pointer: This is already the default on x86-64, and maybe ARM/AArch64 as well (I don't have those ABIs thoroughly memorized). * -Wl,-z,now: Dynamic symbol resolution has to happen at load time rather than lazily. This can cause issues if you're relying on a symbol to be provided by a shared library you're loading dynamically (not a common case, as most people are liable to use dladdr instead). * -Wl,-z,relro: Make sections that need to be writable only for dynamic relocations be read-only post-relocation-fixup phase. * -Wl,-z,defs: Make it a linker error if there's a symbol that isn't available in the main executable/library you're building or any of the dynamic libraries you've linked. (Like -Wl,-z,now, this is again something that is unlikely to cause you issues). * -Wl,-pie: This again enables position-independent executables (and should be triggered by -fPIE, so I'm somewhat curious why -fPIE isn't being passed here instead of -Wl,-pie). * -Wl,--no-copy-dt-needed-entries: The secondary effect here is likely what is intended. If you're linking against liba.so, and liba.so depends on libb.so, this prevents the application from using libb.so to provide symbols, at least for the purposes of deciding whether to cause an error for -Wl,-z,defs (it should still load those symbols at runtime anyways).
newman314 5y ago
Also, one can use checksec to confirm that the protections are actually in place. https://github.com/slimm609/checksec.sh https://github.com/slimm609/checksec.sh I happened to be looking at this for Go binaries last night and it seems that -buildmode=pie gets you part of the way there. Was trying to see if full relro was possible with CGO_ENABLED=0 but it seems only partial was achievable in the few hours I spent.
- wbl 5y ago
  Memory safety obviates these other protections.
0xbadcafebee 5y ago
If there's a religion for hating systemd, I want to be one of the high priests.
Seirdy 5y ago
You should probably add noexecstack to your ldflags. I also only use -fstack-protector-strong and -fcf-protection as a fallback in case -fstack-protector-all and -fcf-protection=full cause crashes. I listed some more in https://news.ycombinator.com/item?id=29191311 https://news.ycombinator.com/item?id=29191311
- Seirdy 5y ago
  Late but wanted to clarify/correct for posterity: the reasons why most people don't use "fstack-protector-all" everywhere are typically related to resource usage (not crashes), esp. in constrained environments. I have old hardware so I don't use it everywhere just yet.

loeg 5y ago

Isn’t -gdwarf-2 an odd choice? Wouldn’t you prefer one of the newer, more expressive flavors of DWARF? -g by itself gets you the default, which is newer than 2 (at least for clang).

secondcoming 5y ago

Wouldn't some of this be mitigated by specifying function visiblity? AIUI, when building a shared lib, all functions are visible in case a user wants to hook any functions via, e.g. LD_PRELOAD

Seirdy 5y ago
Yes, fvisibility=hidden is a great addition; combined with LTO and a Clang toolchain, you can also add fsanitize=cfi. The CFI sanitizer adds a 1% perf penalty for a significant exploit mitigation. It complements -fcf-protection=full nicely. You can also add fsanitize=shadow-stack (ARM) or fsanitize=safe-stack (x86_64) for stronger protection than -fstack-protector-all. This will cause many programs to crash.
- DyslexicAtheist 5y ago
  much appreciated thanks!!
  - Seirdy 5y ago
    Also you should skip ssp-buffer-size since fstack-protector-strong (let alone fstack-protector-all) should protect stacks regardless.

gavinray 5y ago

... please don't copy paste without certainty of what it does Would you be willing to explain why this specific set of flags (I realize I could google them all, but I also realize that some flags have interactions with other flags and trying to find those is not straightforward)? Genuinely interested, not holding you accountable for my computer exploding.

yjftsjthsd-h 5y ago
If nothing else, I'd like to call out -Werror as a footgun when shipping for other people to use. By all means use it for dev work when you control the environment, but as an end-user (well, downstream, at least) it's a problem when packages outright break because I'm building with a newer compiler version that added more warnings.
- DyslexicAtheist 5y ago
  absolutely. you don't want to have -Werror in a fast moving FOSS project. It depends on what you're doing. I compile against latest compiler versions in a CI pipeline that I want to fail. It's probably not how you want to ship in FOSS projects.
jcranmer 5y ago
Not OP, but here goes: * -fPIE : Compile as a 'position-independent executable'. This allows code and data sections of the executable to be installed at random locations in the address space, and comes with a mild cost due to needing extra indirections to handle position-independent code. * -Wformat-security: adds some extra warnings around possible misuse of printf and scanf. * -fstack-protector-strong --param=ssp-buffer-size=4: adds extra code in functions to check that stack buffer overflows likely haven't occurred. The second bit does it for every variable at least 4 bytes in size. * -fcf-protection: this enables Intel CET instructions to check control flow integrity. This essentially causes the hardware to have a shadow stack and other tracking bits to prevent ROP attacks from occurring, but it does require very new hardware to work correctly. * -Wimplicit-fallthrough: warns if switch cases don't have breaks. * -D_FORTIFY_SOURCE=2: this causes several basic C functions (such as memcpy) in glibc to compile in a somewhat more secure manner, namely aborting the program if it can detect that it's going to overflow the bounds of an object. The '2' level adds extra checks that prohibits some legal C behavior (for example, buffer overflows that run into a different subobject of the same object). * -s: Strip the resulting binary after linking. * -fomit-frame-pointer: This is already the default on x86-64, and maybe ARM/AArch64 as well (I don't have those ABIs thoroughly memorized). * -Wl,-z,now: Dynamic symbol resolution has to happen at load time rather than lazily. This can cause issues if you're relying on a symbol to be provided by a shared library you're loading dynamically (not a common case, as most people are liable to use dladdr instead). * -Wl,-z,relro: Make sections that need to be writable only for dynamic relocations be read-only post-relocation-fixup phase. * -Wl,-z,defs: Make it a linker error if there's a symbol that isn't available in the main executable/library you're building or any of the dynamic libraries you've linked. (Like -Wl,-z,now, this is again something that is unlikely to cause you issues). * -Wl,-pie: This again enables position-independent executables (and should be triggered by -fPIE, so I'm somewhat curious why -fPIE isn't being passed here instead of -Wl,-pie). * -Wl,--no-copy-dt-needed-entries: The secondary effect here is likely what is intended. If you're linking against liba.so, and liba.so depends on libb.so, this prevents the application from using libb.so to provide symbols, at least for the purposes of deciding whether to cause an error for -Wl,-z,defs (it should still load those symbols at runtime anyways).

newman314 5y ago

Also, one can use checksec to confirm that the protections are actually in place. https://github.com/slimm609/checksec.sh https://github.com/slimm609/checksec.sh I happened to be looking at this for Go binaries last night and it seems that -buildmode=pie gets you part of the way there. Was trying to see if full relro was possible with CGO_ENABLED=0 but it seems only partial was achievable in the few hours I spent.

wbl 5y ago
Memory safety obviates these other protections.

0xbadcafebee 5y ago

If there's a religion for hating systemd, I want to be one of the high priests.

Seirdy 5y ago

You should probably add noexecstack to your ldflags. I also only use -fstack-protector-strong and -fcf-protection as a fallback in case -fstack-protector-all and -fcf-protection=full cause crashes. I listed some more in https://news.ycombinator.com/item?id=29191311 https://news.ycombinator.com/item?id=29191311

Seirdy 5y ago
Late but wanted to clarify/correct for posterity: the reasons why most people don't use "fstack-protector-all" everywhere are typically related to resource usage (not crashes), esp. in constrained environments. I have old hardware so I don't use it everywhere just yet.