How are those changes going to affect platforms other than Linux?

Yes, it doesn't have any check for the other platform :-/ feel free to fix or close it then.
Btw, is there a dedicated SecurityDev for NixOS ?

Supported platforms/known issues #7214 (comment)

These changes shouldn't go in until they're fixed for non-Linux.

But, doing this in every security-critical expression is quite unscalable anyway. What would be better is instead if there was a component of mkDerivation that could automatically flick the right extensions on, for example, if you enabled enableHardening on the expression. This in turn can be a no-op (or use totally different options) on, say, OS X.

Ideally such a flag would actually be the default and you would have to flick them off for particular expressions (perhaps speed sensitive ones, GCC itself for example probably wouldn't need it and only be slowed down), but that's a huge discussion waiting to happen.

Doesn't Gentoo's "hardened" profile enable those features globally through gcc's spec file? That seems like a feasible approach. Passing special flags to the build is hard because no two package accept additional flags through the same mechanism. Maybe we could use NIX_CLAGS to pass them, though.

Right, I was thinking of NIX_CFLAGS via gcc-wrapper. Using a GCC spec file would work as well, I forgot about those.

Either way, I think this is The Right Way to go for hardening these programs and in general hardening a larger portion of the NixOS installation quickly, because adding these flags into every expression will quickly become untenable, obviously.

@thoughtpolice yeah, I've been thinking on the same global-wide switch actually.
It would be generally a great option for security-concerned to have Hardened NixOS .
We could benefit from:
https://wiki.debian.org/Hardening
https://wiki.gentoo.org/wiki/Hardened_Gentoo
https://wiki.gentoo.org/wiki/Project:Hardened
https://wiki.ubuntu.com/Security/Features
http://hardenubuntu.com/
Fedora Hardening
etc..

https://www.securix.org/about/

+1 to have those flags global and enabled by default for linux. I think we should have a discussion about each flag and the impact it has on compiled programs.

thinking even further, we could have NixOS Hardened to pass the SCAP compliance checker (XCCDF+OVAL)
e.g.
https://securityblog.redhat.com/2013/11/13/automated-auditing-the-system-using-scap-2/
https://fedorahosted.org/scap-security-guide/wiki/usageguide

There are a few dimensions to something like a 'Hardened NixOS':

• Binary hardening (e.g. full non-lazy PLT entries with RELRO protection, PIE with SSP and FORTIFY_SOURCE (and possibly --ssp-buffer-size=1), non-optimization of integer-overflow tests, full stack protection e.g. -fstack-protector-all, or with GCC 4.9 we could be more lenient and go with -fstack-protector-strong.)
• Binary determinism. This is Preview: deterministic build #2281 for system_tarball_pc.
• Process and service hardening (e.g. private /tmp for daemons, restricted /dev access, disallowing /home.) Lots of these can be done via systemd with minimal surface area changes (the tor module is an example of one that does decent enforcement).
• Kernel enhancements; grsecurity support works with my module, but it's a bit unwield-ly, and I think it could be simplified maybe. Otherwise I think this works pretty well.
• MAC/RBAC. We already have AppArmor in place for particular services but we A) don't enable it by default or B) enforce policies on many things; I think Transmission has a policy, but that's all. This is also low effort. (FWIW, I decidedly went with supporting AppArmor because the policies are simple as opposed to SELinux, which I think is an important selling point when you have to maintain them with a small team).
  • grsecurity comes with gradm which is totally awesome, but I think may have some bugs on NixOS, and we haven't figured out the policy on how to manage these rules yet (e.g. to reconcile with the self learning mode).

This component addresses 1. We should really address all of them. I'll create a ticket for this as a sort of meta-issue, thanks.

I have created #7220 with my thoughts, which would subsume this series of pull requests. (In fact, we might want to back out bed68ea/#7189 right now as well, so it doesn't slip by annoyingly.)

@thoughtpolice Thank you for the #7220 , it's pretty comprehensive ! :)
Regarding backing out the bed68ea #7189 , IMHO postfix (and any other listening daemon) is highly sensitive daemon that would be good to keep hardened.
It would be better to add checks like CLANG vs GCC, and host-based checks, e.g. ia64 & alpha (NO {ld -z relro, SSP}), hppa & m68k (NO {PIE}), ... and others in case someone finds/reports a failure.

I understand that there is a performance drop, but personally I'd place security over performance as a default. And folks who prefer performance can simply drop the security or find a compromise =)

@Arno01 can we close these PRs and have a more general discussion before we move forward?

@domenkozar yes, of course. Thank you

Closing in favor of #12895.