On Tue, Nov 19, 2013 at 2:12 AM, Marc Weber <marco-owe...@gmx.de> wrote:
> > Securing nixos > I guess we all want to be secure :) > > I'd also like you to start a wiki page talking about > - what could be done > - what you want to be done > - how to verify that the goal has been achieved (if this does make > sense) > - what else could be done to have a secure system .. > - how to detect that a "secure" system was hacked (or what do you try to > protect against ?) > Ok, if nobody disagrees I will create a wiki page and do a write-up sometime this week. > > NixOS doesn't have many users, and hardened NixOS would have even less of > > them, then perhaps this is not necessary at the moment... > Maybe you should also try to tell us why some people of us would not > like to adopt your changes, eg are there obvious downsides /limitations > of the changes you propose ? > Well, regarding the RSBAC and grsecurity kernel NixOS module ideas, there should be no downsides unless the user enables them, and they would be rather self-contained, so I don't think these are controversial. They can be incrementally improved over time. However, I haven't developed these yet. Regarding actually allowing software to run under a grsec/PaX kernel, then there are additional complications. Specifically, there will be software that will not compile or run until either they are patched or some protections are selectively disabled in their binaries. These are usually programs that run JIT-compiled code (Chromium/v8, Firefox/spidermonkey, Java VMs, ...), but there are others as well. You can see a (possibly incomplete) list of affected packages here, as used by Arch Linux: https://github.com/nning/linux-pax-flags (Note that the simple.conf file has the larger list). As you can see, it's a few dozen packages. In order for these software packages to run, they need minor fixes. Normally, we just need to disable a flag in the compiled binaries or marking a stack as non-executable, so usually it's just 2-4 lines of additional Nix code for each affected package. However, this code is not enabled unless users enable this feature in their nixpkgs.config, so by default we do not change how packages are compiled, and therefore there should be no regressions for people who do not wish to use these features. I am committing myself to at least fix the packages that break on my system (currently 8 out of 251), but as people file issues I would do my best to fix others as well. The other downside is that Hydra does not currently build packages with this feature enabled, so if a user enables it, he will currently have to rebuild their entire NixOS system from source. Regarding PIE+SSP, I do not know to what extent there will be downsides, but I think Ubuntu enables it by default, so it shouldn't have too many bad consequences, as long as, again, packages are fixed to compile/run correctly... Thanks!
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev