add nix build files #27
Conversation
Allows installation via nix from the repository itself on NixOS and other Linux distribution that have Nix (i.e. Archlinux/Debian). ``` $ nix-build $ ./result/bin/kconfig-hardened-check $ nix-env -f . -i ``` It also provides an development environment for `nix-shell` with setuptools and python in path ``` $ nix-shell ```
|
These are all possible kernel configurations: nixpkgs-linux_latest-libre-config.txt |
|
This is the output for our hardened kernel: |
|
cc @fpletz @andir @flokli @NeQuissimus regarding security/kernel maintenance. |
|
There is no (official) open source grsecurity for recent kernels. But for the other options, I'd be interested in a discussion in the nixpkgs repo. |
|
Hello @Mic92,
I would like to have only the default and hardened config for NixOS. Hello @NeQuissimus,
Yes.
I would be glad to join that discussion.
It could be useful for making a decision about enabling kernel hardening config options. @Mic92 @fpletz @andir @flokli @NeQuissimus, Thanks! |
|
I was thinking of minipli but I guess those are only for 4.9. I opened NixOS/nixpkgs#76850, which links to the kernel flags we set for the standard kernel builds and for the hardened one. |
Fair enough I think the other changes that are actually part of this pull request should be still useful though. |
Add CONFIG_SECURITY_SAFESETID (y) and CONFIG_SECURITY_WRITABLE_HOOKS (n). Refers to the pull request #27.
|
Hi, I haven't tested NixOS yet, is there a quick and easy way to retrieve the kernel configuration or it's only dynamically generated? Beside the point, I'm not a fan of that : |
|
@HacKurx It's generated by nix code. Can you explain why a RANDSTRUCT read from /dev/random is better than a checksum over the linux kernel tarball? From my understanding, once that a package is build, one could extract the seed from the build. In that way reproducible builds would give us other properties i.e. verifying a correct build. |
|
@Mic92 I agree with you. I think it's fair to say that any compile-time randomization is rendered (nearly) pointless by publishing the image. In our case, the value is likely to change whenever source/config changes, so might be considered "better" than a static seed value (whether it makes any real difference is another matter). I think users who really care about this type of mitigation should build their own kernel with a custom seed (support for this was added in a later patch, iirc). |
|
@HacKurx note that I wouldn't mind including more information in the seed construction to further increase the likelihood that it will differ between builds, but whatever is added needs to preserve determinism (in the sense that same inputs give same output). Reproducibility is a key goal for Nix/NixPkgs and usually overrides other concerns. In this case, I think giving users of the prebuilt image a weak(ened) variant of the mitigation while making it easy to supply a custom seed is a more than fair tradeoff, especially given that the full benefit of this type of mitigation can only be realized with a self-built package anyway. |
|
Hello @Mic92! |
|
@a13xp0p0v just add: as a shebang. Nixpkgs has python3.6 and the script depends nix anyway. |
|
Thanks for prompt reply!
I got kernel configs and added hardened one to the collection: 4768e21 Thanks! |
|
My mistake it should have been: |
No description provided.