Consider passing hardening ELF flags to LDFAGS in Makefile

[Dentrax]

We need to ensure that the linker resolves all dynamically linked functions at the beginning of the execution, and then makes the GOT read-only. This technique is called RELRO and ensures that the GOT cannot be overwritten in vulnerable ELF binaries. ¹

gcc -g -O0 -Wl,-z,relro,-z,now -o <binary_name> <source_code>

In Go equivalent:

-extldflags=-zrelro -extldflags=-znow

An example implementation to Vault: https://github.com/hashicorp/vault-csi-provider/pull/143/files by @developer-guy

- trimpath increases build reproducibility. Per default full file paths are added to the go binary so two users will very likely have different binaries build even though the code is the same.
- w No DWARF (reduces binary size)
- s No symbol table (even less binary size)
- znow and zrelro Hardening, adds runtime costs.

Footnotes

1. https://www.redhat.com/en/blog/hardening-elf-binaries-using-relocation-read-only-relro ↩

[developer-guy]

feel free to assign it to us, we're willing to do it🙋🏻‍♂️

[ellistarn]

I'm not familiar with this, perhaps @spring1843 is? Are there any tradeoffs to this? Is there any plans for golang to set this as default if it's considered best practice?

[spring1843]

There are known and unknown trade offs to each of these.

Some are developer convenience for example without trimpath on a SIGSEGV or panic you see absolute full path to the problem:

goroutine 1 [running]:
main.main()
        /Users/username/go/src/github.com/aws/karpenter/test/main.go:8 +0x19

Without it you see a trimmed path:

goroutine 1 [running]:
main.main()
        github.com/aws/karpenter/test/main.go:8 +0x19

The former has the benefit that during development you can simply click on that message and the IDE will take the developer exactly to where the problem is. In the latter the developer has to find the file and the line and column number.

It does make sense to have trimpath during the process in which our release artifacts are made. Although even then it doesn't seem hugely beneficial. What is the value of build reproducibility (all users building identical executables)? If anything it seems to go against the idea of hardening against ROP attacks.

The others (zrelro, znow, -buildmode=pie) have tradeoffs in the way the binary is built and executed (both at startup and while executing) as they significantly change the way the binary is structured.

I'm looking deeper into each of these and we should certainly take baby steps i.e. try, and evaluate each change separately and only apply after having studied/experienced the consequences.

[developer-guy]

maybe we could start with -trimpath and -buildid= to provide better reproducibility, then we can start hardening the binary with RELRO and PIE compilation. There are similar ongoing works on both vault-csi-provider and cosign, so, I'm sharing the links that might be useful:

• feat: add bunch of ldflags for reproducibility hashicorp/vault-csi-provider#143
• hashicorp/vault-csi-provider@659b03f
• sigstore/cosign@f436d76
• enhance reproducibility by passing additional ldflags sigstore/cosign#1450

WDYT @spring1843 @Dentrax ?

[spring1843]

@developer-guy What is the value of build reproducibility (all users building identical executables)?

[spring1843]

After looking deeper into this I'm inclined to not make any of these changes.

Here's a relevant thread about the similar issues: https://groups.google.com/g/golang-nuts/c/Jd9tlNc6jUE/m/fJodJUqZV-YJ

TL;DR : This family of problems exists in C and C++ where bad memory management can lead to buffer overflows that cause security concerns. Go does not permit any of those problems by design hence there is really no need to have RELRO as a defense against ROP. The only exception here is if there are C libraries used by the Go code in an unsafe way, then the Go binary will also expose the same problems.

All of these changes have a cost specially in allowing us to use Go's debugging features. The cost of this therefore outweighs its benefits.

On the other hand it is a good idea for us to completely disable CGO using the CGO_ENABLED flag after ensuring none of our dependencies use it, thereby disallowing the addition of CGO into the code base of Karpenter and its dependencies. As a result we will be protected from the bugs and problems that exists in C libraries.

[spring1843]

Closing the issue please feel free to reopen if you can provide more reasons to include any of the flags.