[Nix-dev] Hardened NixOS

[Ricardo M. Correia]

On Tue, Nov 19, 2013 at 2:12 AM, Marc Weber <marco-oweber at 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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20131119/56d8a43c/attachment-0001.html