Nixpkgs: Create a "high security" profile

[spacekitteh]

This is an easy way to reduce the barrier to creating a secure NixOS system.

It could include such things as:

• haveged
• containers
• fail2ban
• clamav
• grsec
• dnscrypt
• tcpcryptd

also, optionally networking layers in separate contains such as:

• tor
• cjdns
• i2p

and then use iptables to route all traffic through those containers.

[spacekitteh]

@joachifm @grahamc @thoughtpolice you seem the most likely to be interested. What do you think?

(btw pls set labels as security, enhancement)

[langston-barrett]

@spacekitteh What are you envisioning? A boolean option like security.secure-profile = true? Would it just install those packages/modules, or configure them in a meaningful way? Is there any reason why we wouldn't want a "more secure profile" to be the default?

[vcunat]

I suspect it was meant as adding a file into https://github.com/NixOS/nixpkgs/tree/master/nixos/modules/profiles/ . I don't think most people would want to have all that software installed, so it wouldn't make sense to be included by default (i.e. always).

[jpierre03]

@siddharthist some services default configuration requires user inputs.

Typically, fail2ban is used to block and informs. An email notification is common configration.

To me: a default "secure" profile should install and configure with strong default settings.

@spacekitteh what about :

• DNS resolver with DNSSEC enabled
• strong SSH server configuration (https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Modern_.28OpenSSH_6.7.2B.29)

[jpierre03]

From Mozilla's profile to SSH Client setup in configuration.nix

• https://wiki.mozilla.org/Security/Guidelines/OpenSSH#Modern

  programs.ssh.extraConfig = ''
    # Ensure KnownHosts are unreadable if leaked - it is otherwise easier to know which hosts your keys have access to.
    HashKnownHosts yes
    # Host keys the client accepts - order here is honored by OpenSSH
    HostKeyAlgorithms [email protected],[email protected],ssh-ed25519,ssh-rsa,[email protected],[email protected],[email protected],ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256

    KexAlgorithms [email protected],ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
    MACs [email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,[email protected]
    Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
  '';

[joachifm]

One possibility that occurrred to me is setting an internal flag in the hardened profile that other modules can condition on to select "paranoid" defaults (sacrificing features and/or performance).

Other than that I think it makes sense to continue this issue via concrete PRs against the hardened profile.