
Hardening Compiler Flags for NixOS - ivank
https://blog.mayflower.de/5800-Hardening-Compiler-Flags-for-NixOS.html
======
colemickens
Excellent! Really, anything to propel Nix(OS) or Guix(SD) forward gets a huge
thumbs up in my book. Nix is one of those things that I explain and then have
people telling me I'm wrong and/or an idiot because they can't believe that
you can have a distribution based on building packages from source, backed by
a binary cache. If you think Snappy or Flatpak/Xdg-App are cool, you owe it to
yourself to look at Nix/Guix, which provide a superset of the features
provided by Snappy. And then some.

NixOS + NixOps means I can have a single declarative file that describes the
state of my cloud VMs, cloud load balancer, cloud Traffic Manager... _plus_
the exact software on the VMs (all the way down to the exact checkout of gcc
used to compile everything and the nginx configurations)... literally
everything is snapshotted and revertable.

If it weren't for a systemd-related bug, I'd have a one-command way of getting
a Kubernetes cluster booted in Azure via NixOS, where upgrading a cluster
would simply require editting a single file and re-running the nixops tool.

I wish more people knew about NixOS. You know how everyone writes pie-in-the-
sky blogposts about the "next-gen" Node.JS package manager? Yeah, well, Nix
already packages NodeJS libraries/apps, plus Rust libraries/apps, plus Go
libraries/apps, plus Python libraries/apps, etc, etc.

~~~
aidenn0
"If it weren't for a systemd-related bug..."

I've started so many sentences with those exact words, and it kind of saddens
me. I'm still hoping that the problems with systemd aren't fundamental to its
architecture, and it just needs some more polishing. It certainly is
incredibly ambitious as it aims to replace on the order of a dozen different
pieces of software, so some hiccups are to be expected.

~~~
digi_owl
Nah, its the mentality within the project.

One that i think can be summed up as "code, compile, push, repeat".

More and more it seems that the incoming generation treats everything like a
web site that they can change at whim. Likely because they have had the
internet and source repositories the whole time, and thus do not know the
value of a truly stable and maintained system.

------
oconnore
If there are any other roadblocks keeping you from using Nix in your
infrastructure: keep in mind you can overlay Nix on top of another
distribution. This way you can get a more mature base system and still have
all the benefits of Nix available when you want it.

~~~
Joof
Good to know. Last I checked it had trouble with steam which kept me from
trying it on my home machine.

~~~
Poldi
Just tested steam last week without any issues :)

~~~
Joof
Good to hear, I may have to give it another shot.

------
ramblenode
I am glad to see this finally get merged--great work!

For those who are curious about the declarative OS and package ecosystem
offered by NixOS, the newest stable release (16.09) is coming in the following
weeks.

~~~
k__
Is the new, more user friendly, CLI in 16.09?

~~~
ramblenode
Judging by the commits I've seen, I'm guessing no. Not sure what the time
frame on this is, but it seems a lot of people are looking forward to it.

------
cstrahan
Awesome work, Franz et al!

~~~
frio
Absolutely. NixOS is awesome. The lack of decent hardening by default was the
only thing preventing me from using it more confidently. I'm thoroughly
impressed by the many people who have worked hard to push this through. Thanks
so much to everyone who's worked on this!

------
AstralStorm
Talking about stack protector providing any sort of guarantee makes me
chuckle. Both this and fortify are relatively easy to work around. PIC/PIE are
the real protection, and but still nowhere near foolproof. Also new Address
Sanitizer is not mentioned.

~~~
netheril96
Address Sanitizer slows down execution a lot. It should only used for testing
purposes, the same as -O0.

~~~
masterleep
What if you care more about unsafe pointer access than speed?

~~~
anon1385
Address Sanitizer isn't designed to be used in production. See this thread:
[http://seclists.org/oss-sec/2016/q1/363](http://seclists.org/oss-
sec/2016/q1/363)

ASAN is great at detecting many unintentional memory errors, but it's not
designed to thwart malicious attacks.

If you need a specific example of ASAN binary being exploited then see:
[http://int3pids.blogspot.ch/2015/04/confidence-2015-teaser-q...](http://int3pids.blogspot.ch/2015/04/confidence-2015-teaser-
quarantine-write.html)

~~~
AstralStorm
Correct, but it still prevents a large set of attacks. Instead, we need an
equivalent that is more focused on security than bug detection. CPI is the
mechanism for the future with somewhere below 10% overhead.

------
hannob
anyone knows why they disable -pie by default? I know a lot of others do so as
well, but this should be really pushed forward and be the default. Full ASLR
is most likely the strongest exploit mitigation mechanism that's available
right now.

~~~
grhmc
We disabled -pie so we could get it merged in. We would like pie enabled by
default (for the reasons you say) but didn't want perfect be the enemy of good
here.

