Re: [Nix-dev] Hardened NixOS
On 11/19/2013 03:27 AM, phree...@yandex.ru wrote: Centralized building and security are often at odds. Say, certain grsecurity kernel features only make sense if you are running a unique, randomized build. Probably if you dig deep enough you'll find some features in gcc which introduce similar trade-offs. IIRC the randomization is always done at runtime, e.g. when loading the binary. I do think distros use such features with equal binaries. Vlada smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Hardened NixOS
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 ?) 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 ? My two cents Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Hardened NixOS
On Tuesday, November 19, 2013 01:58:28 AM Ricardo M. Correia wrote: I am currently working on integrating grsecurity/PaX and making various software packages work under a grsec-enabled kernel (well, the packages I use): https://github.com/NixOS/nixpkgs/pull/1187 With those patches and a couple of unpublished workarounds I have a basic XFCE desktop + Firefox/Chromium browsers working under a grsec/PaX-enabled kernel (KDE does not start up yet, though). I am now working on a patch to the gcc derivation which fixes a broken build of OpenJDK, due to gcc's precompiled headers feature not liking randomized mmap addresses. This patch alone causes my entire NixOS system to be rebuilt from source, though. Looking forward, I would like to develop a NixOS module which provides an adequate grsecurity kernel and kernel config, and later integrate features similar to the ones used in the Hardened Gentoo project, especially an improved compiler toolchain which would generate position-independent code (PIE) and stack-smashing protection (SSP), if these are not enabled already. In the future, I am also interested in developing a NixOS module for grsecurity's RSBAC system. I'm very happy to know that someone's working on this and this person is not me :) I was wondering if anybody else is interested in having these security enhancements to NixOS, some of which would of course only be enabled optionally? My (totally unscientific) estimate is that the % of paranoid people in #nixos is only smaller than in specialized distros like Tails. Also, you shouldn't underestimate the number of people who would be happy to tick the harden checkbox if they don't expect any negative consequences. What do you think would be the best approach for development? I'm thinking of a few options: * I keep developing these patches in a piecemeal fashion and keep asking for pull requests into NixOS master as I go along, as I've been trying to do If it can be merged it should be merged. If it can be mainstreamed with some modifications, they should be discussed and implemented early to avoid headaches later. Having Hydra precompile packages with these features enabled would of course be very convenient if there is a relevant number of other interested users, since otherwise the whole NixOS system has to be built from source (because these patches will touch gcc). However, taking into account that NixOS doesn't have many users, and hardened NixOS would have even less of them, then perhaps this is not necessary at the moment... Centralized building and security are often at odds. Say, certain grsecurity kernel features only make sense if you are running a unique, randomized build. Probably if you dig deep enough you'll find some features in gcc which introduce similar trade-offs. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Hardened NixOS
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
Re: [Nix-dev] Hardened NixOS
Yes, start the wiki page. Don't forgett that nixos has the nesting features for builds. Thus you can build i686,x86_64 and hardened/not hardened systems at the same time. Ther is not much which can go wrong other than that you have to download nix* stuff twice. Its on my todo list to improve the perl based grub builder to allow such showing such 'sub-systems' in the boot menu again. The feature already was there when the bash builder script was used. Might take some time till I manage to do so. Having a very short writeup about - feature -X description see link foo potential issues: .. would be perfect. Why do you fear people disagreeing ? Let me rethink: there are 3 types of tools I use most: - browser (This will not be hardened for JIT reasons?, this could benefit little) - email (this could benefit a lot) - editor (I trust scripts anyway) - web servers (this could benefit, unless I use nodejs ..) Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
