CFLAGS for downstream

[jrmoserbaltimore]

As per docker-library/php#272

Would it make more sense to drop that into the Debian Dockerfile, so as to immediately apply to all downstream images using compiled-from-source automake code?

This is a rather complex question. In general, it's well-understood that the stack smash protector, position-independent executable, and linker optimization flags do not break anything; most distributions use them as standard in all packages now. On the other hand, a change at the level of the base Docker image would hit everything at once, potentially causing confusion when a rebuild fails.

Technically, the risk is near-zero (approximately nothing should break, and anything that does break is easily-fixed by the maintainers); the risk of not putting SSP and PIE CFLAGS into the environment is loads of vulnerable applications on Docker hub with no mitigation. That risk is, of course, not Debian's concern per-se.

The effort to get downstream applications vendors to update their containers is as big as every single application; while the effort to fix broken applications is as big as only those which break, adding lines to unset CFLAGS and LDFLAGS in the environment. Efficient.

[tianon]

While I can sympathize with the sentiment, I think it would be dangerous for us to be adding these as a blanket at this level. In my mind, if the Debian project feels that these are the appropriate defaults for all compilation within a Debian environment, then they ought to adjust GCC's defaults directly to match these values (or petition GCC upstream to do so).

[jrmoserbaltimore]

I don't believe that's wise. I'd prefer a compiler which behaved consistently with expectations, at least as best as that can be met.

I'd suggest adding these flags to the next release of Debian's Docker image, rather than current (i.e. not to debian:jessie). If you're inclined to upgrade to a new version of Debian for your Docker base image without testing, you deserve what you get; I will agree that adding them to a current release and suddenly changing a lot of stuff that's built FROM debian:jessie would be impolitic.

The considerations are thus, to my senses:

• No flags means basically all official repositories using a latest version are building from source without protection simply because the maintainers aren't aware of security flags.
• Environment flags means all official repositories automatically get security flags. If they break when they migrate from debian:jessie to the next release, then they can set CFLAGS="" and so forth to remove the offending flags.
• A modified compiler has far-reaching implications. If something breaks, a thorough examination won't reveal why; you'd have to dig into the compiler package and identify that gcc's defaults were modified--something heavily-unexpected. Such a change affects not only downstream Docker images, but also Debian proper, Ubuntu proper, Mint proper, and so forth; this is highly-impolitic.

I feel these are appropriate defaults for compilation within downstream Docker images based on Debian. Debian's own packages are built with these flags, as per dpkg-buildflags:

root@a2b83bad509f:/# dpkg-buildflags 
CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security
CPPFLAGS=-D_FORTIFY_SOURCE=2
CXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security
FCFLAGS=-g -O2 -fstack-protector-strong
FFLAGS=-g -O2 -fstack-protector-strong
GCJFLAGS=-g -O2 -fstack-protector-strong
LDFLAGS=-Wl,-z,relro
OBJCFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security
OBJCXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security

In essence, I am only suggesting building with similar compilation flags, although mine are different. The most conservative would be -fstack-protector-strong and -D_FORTIFY_SOURCE=2; the other flags (-Wl,-O1 and such) are largely optimizations (sorting hash buckets and adding an ELF section with an additional hash type) and would require more consideration at this level.

I'd shy away from -g, -O2, and so forth in an upstream distro base image.

[tianon]

This repository is now deprecated in favor of https://github.com/debuerreotype/docker-debian-artifacts, which builds reproducible Debian rootfs tarballs using https://github.com/debuerreotype/debuerreotype. 👍