nixpkgs/nixos/modules/security/dhparams.nix

161 lines
5.5 KiB
Nix
Raw Normal View History

2017-02-10 17:36:36 +00:00
{ config, lib, pkgs, ... }:
with lib;
2017-02-10 17:36:36 +00:00
let
cfg = config.security.dhparams;
paramsSubmodule = { name, config, ... }: {
options.bits = mkOption {
type = types.addCheck types.int (b: b >= 16) // {
name = "bits";
description = "integer of at least 16 bits";
};
default = 4096;
description = ''
The bit size for the prime that is used during a Diffie-Hellman
key exchange.
'';
};
options.path = mkOption {
type = types.path;
readOnly = true;
description = ''
The resulting path of the generated Diffie-Hellman parameters
file for other services to reference. This could be either a
store path or a file inside the directory specified by
<option>security.dhparams.path</option>.
'';
};
nixos/dhparams: Introduce a 'stateful' option This option allows us to turn off stateful generation of Diffie-Hellman parameters, which in some way is still stateful as the generated DH params file is non-deterministic. However what we can avoid with this is to have an increased surface for failures during system startup, because generation of the parameters is done during build-time. Another advantage of this is that we no longer need to take care of cleaning up the files that are no longer used and in my humble opinion I would have preferred that #11505 (which puts the dhparams in the Nix store) would have been merged instead of #22634 (which we have now). Luckily we can still change that and this change gives the user the option to put the dhparams into the Nix store. Beside of the more obvious advantages pointed out here, this also effects test runtime if more services are starting to use this (for example see #39507 and #39288), because generating DH params could take a long time depending on the bit size which adds up to test runtime. If we generate the DH params in a separate derivation, subsequent test runs won't need to wait for DH params generation during bootup. Of course, tests could still mock this by force-disabling the service and adding a service or activation script that places pre-generated DH params in /var/lib/dhparams but this would make tests less readable and the workaround would have to be made for each test affected. Note that the 'stateful' option is still true by default so that we are backwards-compatible with existing systems. Signed-off-by: aszlig <aszlig@nix.build> Cc: @Ekleog, @abbradar, @fpletz
2018-04-26 04:38:02 +00:00
config.path = let
generated = pkgs.runCommand "dhparams-${name}.pem" {
nativeBuildInputs = [ pkgs.openssl ];
} "openssl dhparam -out \"$out\" ${toString config.bits}";
in if cfg.stateful then "${cfg.path}/${name}.pem" else generated;
};
in {
2017-02-10 17:36:36 +00:00
options = {
security.dhparams = {
params = mkOption {
description =
''
Diffie-Hellman parameters to generate.
The value is the size (in bits) of the DH params to generate. The
generated DH params path can be found in
<literal>config.security.dhparams.params.<replaceable>name</replaceable>.path</literal>.
2017-02-10 17:36:36 +00:00
<note><para>The name of the DH params is taken as being the name of
the service it serves and the params will be generated before the
said service is started.</para></note>
<warning><para>If you are removing all dhparams from this list, you
have to leave <option>security.dhparams.enable</option> for at
least one activation in order to have them be cleaned up. This also
means if you rollback to a version without any dhparams the
nixos/dhparams: Introduce a 'stateful' option This option allows us to turn off stateful generation of Diffie-Hellman parameters, which in some way is still stateful as the generated DH params file is non-deterministic. However what we can avoid with this is to have an increased surface for failures during system startup, because generation of the parameters is done during build-time. Another advantage of this is that we no longer need to take care of cleaning up the files that are no longer used and in my humble opinion I would have preferred that #11505 (which puts the dhparams in the Nix store) would have been merged instead of #22634 (which we have now). Luckily we can still change that and this change gives the user the option to put the dhparams into the Nix store. Beside of the more obvious advantages pointed out here, this also effects test runtime if more services are starting to use this (for example see #39507 and #39288), because generating DH params could take a long time depending on the bit size which adds up to test runtime. If we generate the DH params in a separate derivation, subsequent test runs won't need to wait for DH params generation during bootup. Of course, tests could still mock this by force-disabling the service and adding a service or activation script that places pre-generated DH params in /var/lib/dhparams but this would make tests less readable and the workaround would have to be made for each test affected. Note that the 'stateful' option is still true by default so that we are backwards-compatible with existing systems. Signed-off-by: aszlig <aszlig@nix.build> Cc: @Ekleog, @abbradar, @fpletz
2018-04-26 04:38:02 +00:00
existing ones won't be cleaned up. Of course this only applies if
<option>security.dhparams.stateful</option> is
<literal>true</literal>.</para></warning>
2017-02-10 17:36:36 +00:00
'';
type = with types; let
coerce = bits: { inherit bits; };
in attrsOf (coercedTo types.int coerce (submodule paramsSubmodule));
2017-02-10 17:36:36 +00:00
default = {};
example = literalExample "{ nginx.bits = 3072; }";
2017-02-10 17:36:36 +00:00
};
nixos/dhparams: Introduce a 'stateful' option This option allows us to turn off stateful generation of Diffie-Hellman parameters, which in some way is still stateful as the generated DH params file is non-deterministic. However what we can avoid with this is to have an increased surface for failures during system startup, because generation of the parameters is done during build-time. Another advantage of this is that we no longer need to take care of cleaning up the files that are no longer used and in my humble opinion I would have preferred that #11505 (which puts the dhparams in the Nix store) would have been merged instead of #22634 (which we have now). Luckily we can still change that and this change gives the user the option to put the dhparams into the Nix store. Beside of the more obvious advantages pointed out here, this also effects test runtime if more services are starting to use this (for example see #39507 and #39288), because generating DH params could take a long time depending on the bit size which adds up to test runtime. If we generate the DH params in a separate derivation, subsequent test runs won't need to wait for DH params generation during bootup. Of course, tests could still mock this by force-disabling the service and adding a service or activation script that places pre-generated DH params in /var/lib/dhparams but this would make tests less readable and the workaround would have to be made for each test affected. Note that the 'stateful' option is still true by default so that we are backwards-compatible with existing systems. Signed-off-by: aszlig <aszlig@nix.build> Cc: @Ekleog, @abbradar, @fpletz
2018-04-26 04:38:02 +00:00
stateful = mkOption {
type = types.bool;
default = true;
description = ''
Whether generation of Diffie-Hellman parameters should be stateful or
not. If this is enabled, PEM-encoded files for Diffie-Hellman
parameters are placed in the directory specified by
<option>security.dhparams.path</option>. Otherwise the files are
created within the Nix store.
<note><para>If this is <literal>false</literal> the resulting store
path will be non-deterministic and will be rebuilt every time the
<package>openssl</package> package changes.</para></note>
'';
};
2017-02-10 17:36:36 +00:00
path = mkOption {
nixos/dhparams: Introduce a 'stateful' option This option allows us to turn off stateful generation of Diffie-Hellman parameters, which in some way is still stateful as the generated DH params file is non-deterministic. However what we can avoid with this is to have an increased surface for failures during system startup, because generation of the parameters is done during build-time. Another advantage of this is that we no longer need to take care of cleaning up the files that are no longer used and in my humble opinion I would have preferred that #11505 (which puts the dhparams in the Nix store) would have been merged instead of #22634 (which we have now). Luckily we can still change that and this change gives the user the option to put the dhparams into the Nix store. Beside of the more obvious advantages pointed out here, this also effects test runtime if more services are starting to use this (for example see #39507 and #39288), because generating DH params could take a long time depending on the bit size which adds up to test runtime. If we generate the DH params in a separate derivation, subsequent test runs won't need to wait for DH params generation during bootup. Of course, tests could still mock this by force-disabling the service and adding a service or activation script that places pre-generated DH params in /var/lib/dhparams but this would make tests less readable and the workaround would have to be made for each test affected. Note that the 'stateful' option is still true by default so that we are backwards-compatible with existing systems. Signed-off-by: aszlig <aszlig@nix.build> Cc: @Ekleog, @abbradar, @fpletz
2018-04-26 04:38:02 +00:00
description = ''
Path to the directory in which Diffie-Hellman parameters will be
stored. This only is relevant if
<option>security.dhparams.stateful</option> is
<literal>true</literal>.
'';
2017-02-10 17:36:36 +00:00
type = types.str;
default = "/var/lib/dhparams";
};
enable = mkOption {
description =
''
Whether to generate new DH params and clean up old DH params.
'';
default = false;
type = types.bool;
};
2017-02-10 17:36:36 +00:00
};
};
nixos/dhparams: Introduce a 'stateful' option This option allows us to turn off stateful generation of Diffie-Hellman parameters, which in some way is still stateful as the generated DH params file is non-deterministic. However what we can avoid with this is to have an increased surface for failures during system startup, because generation of the parameters is done during build-time. Another advantage of this is that we no longer need to take care of cleaning up the files that are no longer used and in my humble opinion I would have preferred that #11505 (which puts the dhparams in the Nix store) would have been merged instead of #22634 (which we have now). Luckily we can still change that and this change gives the user the option to put the dhparams into the Nix store. Beside of the more obvious advantages pointed out here, this also effects test runtime if more services are starting to use this (for example see #39507 and #39288), because generating DH params could take a long time depending on the bit size which adds up to test runtime. If we generate the DH params in a separate derivation, subsequent test runs won't need to wait for DH params generation during bootup. Of course, tests could still mock this by force-disabling the service and adding a service or activation script that places pre-generated DH params in /var/lib/dhparams but this would make tests less readable and the workaround would have to be made for each test affected. Note that the 'stateful' option is still true by default so that we are backwards-compatible with existing systems. Signed-off-by: aszlig <aszlig@nix.build> Cc: @Ekleog, @abbradar, @fpletz
2018-04-26 04:38:02 +00:00
config = mkIf (cfg.enable && cfg.stateful) {
systemd.services = {
dhparams-init = {
description = "Cleanup old Diffie-Hellman parameters";
wantedBy = [ "multi-user.target" ]; # Clean up even when no DH params is set
serviceConfig.Type = "oneshot";
script =
# Create directory
''
if [ ! -d ${cfg.path} ]; then
mkdir -p ${cfg.path}
2017-02-10 17:36:36 +00:00
fi
'' +
# Remove old dhparams
''
for file in ${cfg.path}/*; do
if [ ! -f "$file" ]; then
continue
fi
'' + concatStrings (mapAttrsToList (name: { bits, ... }:
''
if [ "$file" == "${cfg.path}/${name}.pem" ] && \
${pkgs.openssl}/bin/openssl dhparam -in "$file" -text | head -n 1 | grep "(${toString bits} bit)" > /dev/null; then
continue
fi
''
) cfg.params) +
''
rm $file
done
2017-02-10 17:36:36 +00:00
# TODO: Ideally this would be removing the *former* cfg.path, though this
# does not seem really important as changes to it are quite unlikely
rmdir --ignore-fail-on-non-empty ${cfg.path}
'';
};
} //
mapAttrs' (name: { bits, ... }: nameValuePair "dhparams-gen-${name}" {
description = "Generate Diffie-Hellman parameters for ${name} if they don't exist yet";
after = [ "dhparams-init.service" ];
before = [ "${name}.service" ];
wantedBy = [ "multi-user.target" ];
serviceConfig.Type = "oneshot";
script =
''
mkdir -p ${cfg.path}
if [ ! -f ${cfg.path}/${name}.pem ]; then
${pkgs.openssl}/bin/openssl dhparam -out ${cfg.path}/${name}.pem ${toString bits}
fi
'';
}) cfg.params;
};
2017-02-10 17:36:36 +00:00
}