[Nix-dev] Secure NixOS

[zimbatm]

Hi Seroka,

just a couple of idea:

(1) is really cool but could also be solved by having faster builds and
binary diffs. I really liked the presentation at NixCon and think that it's
a really cool hack but don't understand all of the implications. Just as an
anecdote; ruby has had a release with a CVE attached last August and it
hasn't hit master yet. Build and distribution speed doesn't really matter
until we manage to update the packages in the first place.

(2) might be a bit difficult. I'm not sure NixOS has enough popularity yet
to gather that kind of funding. Also it means going into politics for
example to decide which set of packages are security-supported. That being
said, we could go a long way towards point 2 by having the scraper notify
the package maintainer by email. Having people scan the CVEs is redundant
and should be automated away. Personally I know that if I got an email I
would probably package the new version the same day.

(3) is already supported by adding `security.grsecurity.enable` to your
configuration.nix file.

Personally I feel that NixOS is more resistant to general attacks just
because files are stored in non-conventional places (and is not popular
enough to be a specific target yet). Worms tend to make assumptions about
the availability of files. Having the store mounted read-only also probably
helps a bit to avoid some rootkits.

Cheers,
z


On Sun, 6 Dec 2015 at 19:30 Arseniy Seroka <ars.seroka at gmail.com> wrote:

> Greetings, friends and colleagues.
>
> This is a joint letter by me and Jonn Mostovoy, co-founders of
> Serokell, regarding the state of security in NixOS and a roadmap of fixing
> it.
>
> Hopefully, all of us are using NixOS in our companies, however most of the
> times, NixOS machines are deep within the perimeter and aren't facing wild
> Internet because the reaction time to a newly found vulnerability is very
> long,
> especially compared with the lag in other distros such as Arch Linux. Also,
> proper update process can be tediously slow.
>
> When we faced a problem of making systems that are designed to run 24/7 in
> extremely hostile networks, we have decided to take Arch and, well,
> re-implement some ideas from Nix, because it was cheaper and safer
> business-wise.
>
> Of course, we really want to throw away our pathetic reinvented wheel and
> just
> use NixOS. But for that, three major things have to be done:
> 1. We have to switch to the model of package updates, implemented by
> Nicolas
> and widely announced on NixCon;
> 2. Fund a team of itsec professionals who will perform maintenance of
> nixpkgs;
> 3. Make sure that grsecurity patchsets and other kernel hardening flavors
> (which – ?) are shown to work and integrated into system configuration. Or
> make
> it easy to apply these patchesets if someone needs them.
>
> Regarding (1), it's a question of community / individual effort, to which
> we
> would gladly contribute. Regarding (2) — we think that businesses that use
> NixOS should pool up some resources, make a tender and deal with the itsec
> group who will win thia tender. Again, we are ready to lead the charge
> here. It
> is worth noting, that NixOS community already has a CVE scraper that, if I
> recall correctly, maps CVEs to packages. (3), of course, is also the
> question
> of individual / community effort, what's more, undoubtedly most of people
> who
> run systems that ought to match certain security parameters have already
> made
> expressions for custom kernels, we just need to generalize most common
> usecases
> and put those in configuration set.
>
> If we manage to reach aforementioned goals, from the least secure popular
> distro, NixOS will become the most secure one, which would be a huge win
> both
> for every single member of Nix community and for marketing.
>
> --
> Kindest regards,
> Arseniy and Jonn
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20151207/c7a3dfa4/attachment.html