Hardening Compiler Flags for NixOS
blog.mayflower.de
blog.mayflower.de
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.
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.
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.
Damn, could you explain what this is specifically? Running a Kubernetes cluster on NixOS was next on my list of architectures to test.
Now that there is Azure cloudprovider support in Kubernetes, there's no need for Flannel, so it's possible that this could be made to work...
I ditched NixOS ~4 months ago; I think I had some patches on top of nixpkgs for updating Kube/flannel/etc, and then I have a branch of `nixops` that has the Kubernetes example.
Might be a fun project to pick back up some weekend...
I had a whole bunch of commits on top of nixpkgs, updating Flannel/Kubernetes and fixing up the Kubernetes module: https://github.com/colemickens/nixpkgs/commits/cmpkgs
And then on nixops, a branch that adds in the Kubernetes example. Keep in mind that it doesn't quite work right, and things are possibly broken since my nixpkgs fork is so stale at this point. https://github.com/colemickens/nixops/commit/9e97fd4166e7062...
Hehe, same here. The number of times I'e had people tell me "uh, no, your package-manager/OS can't do that because <reasons that assume FHS dumping ground of libs/headers and global, mutable config state>" -- too many to count :). I'm still trying to find a 30 second sales pitch that manages to get through people's preconceived notions. If I can get someone to look over my shoulder at my terminal for about 5 minutes, that usually blows them away, but that's not always an option (like here in the comments section, vs coworkers at the office).
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.
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...
Why? stack protector prevents overwriting returns and it works. It won't stop overwriting data and that's known. Would you turn it off when compiling anything?
Do you mean it is useless for security, bugs or both?
And the version covering everything on stack is quite expensive. Which is why there is stack-protector-most now.
It introduces vulnerabilities, it's a lot of complex code that wasn't written with hardening in mind, it defeats ASLR, and there are many memory errors it can't detect (which an attacker can use to bypass the checks if they suspect you are using ASAN).
If you want to "harden" your code against an attacker who doesn't know what they are doing then it might help. If you want to stop attacks by somebody skilled then enabling it is making you less secure.
Heck, there is no good debug malloc style library mentioned either plus flags to disable malloc optimizations present in the GCC.