You can now say:
systemd.services.foo.baseUnit = "${pkgs.foo}/.../foo.service";
This will cause NixOS' generated foo.service file to include
foo.service from the foo package. You can then apply local
customization in the usual way:
systemd.services.foo.serviceConfig.MemoryLimit = "512M";
Note however that overriding options in the original unit may not
work. For instance, you cannot override ExecStart.
It's also possible to customize instances of template units:
systemd.services."getty@tty4" =
{ baseUnit = "/etc/systemd/system/getty@.service";
serviceConfig.MemoryLimit = "512M";
};
This replaces the unit options linkTarget (which didn't allow
customisation) and extraConfig (which did allow customisation, but in
a non-standard way).
We used to have the configuration of the kernel available in a
somewhat convenient place (/run/booted-system/kernel-modules/config)
but that has disappeared. So instead just make /proc/configs.gz
available. It only eats a few kilobytes.
This is useful for packages like mosh, which use a wide UDP port range
by default for incoming connections.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
We don't want to hardcode configuration options that the current kernel chose
for us when mounting the filesystem, since the defaults can change in the
future.
i18n.consoleKeyMap maps to KEYMAP=... in vconsole.conf and `loadkeymap'
in stage1. Both of these accept paths to a keymap file in addition to
a string containing the name of the keymap.
With this commit, it's possible to use your own keymap via:
i18n.consoleKeyMap = ./path/to/something.kmap
PostgreSQL defaults to having 'postgres' as the superuser. NixOS should
use this default name to provide a less surprising result to people who
enable services.postgres.
There are two fixes in this commit.
Firstly, I am creating proper symlinks for the Alias= definitions in the
.service files. This achieves the same result as `systemctl enable`, and
I think is preferred over `mv`.
Secondly, `networkmanager-init` now wants `NetworkManager.service`,
along with `ModemManager.service`. ModemManager does not depend on
NetworkManager (according to `systemctl list-dependencies ModemManager`),
thus NetworkManager never got started on boot.
It is parameterized by a function that takes a name and evaluates to the
option type for the attribute of that name. Together with
submoduleWithExtraArgs, this subsumes nixosSubmodule.
The mutableUsers feature uses `chpasswd` to set users passwords.
Passwords and their hashes were being piped into the program using
double quotes ("") to escape. This causes any `$` characters to be
expanded as shell variables. This is a serious problem because all the
password hash methods besides DES use multiple `$` in the hashes. Single
quotes ('') should be used instead to prevent shell variable expansion.
* Bump bumblebee to 3.2.1
* Remove config.patch - options it added can be passed to ./configure now
* Remove the provided xorg.conf
Provided xorg.conf was causing problems for some users,
and Bumblebee provides its own default configuration anyway.
* Make secondary X11 log to /var/log/X.bumblebee.log
* Add a module for bumblebee
Without this the HTML manual and manpage is quite unreadable (newlines
are squashed so it doesn't look like a list anymore).
(Unfortunately, this makes the source unreadable.)
Security-relevant changes:
* No (salted) passphrase hash send to the yubikey, only hash of the salt (as it was in the original implementation).
* Derive $k_luks with PBKDF2 from the yubikey $response (as the PBKDF2 salt) and the passphrase $k_user
(as the PBKDF2 password), so that if two-factor authentication is enabled
(a) a USB-MITM attack on the yubikey itself is not enough to break the system
(b) the potentially low-entropy $k_user is better protected against brute-force attacks
* Instead of using uuidgen, gather the salt (previously random uuid / uuid_r) directly from /dev/random.
* Length of the new salt in byte added as the parameter "saltLength", defaults to 16 byte.
Note: Length of the challenge is 64 byte, so saltLength > 64 may have no benefit over saltLengh = 64.
* Length of $k_luks derived with PBKDF2 in byte added as the parameter "keyLength", defaults to 64 byte.
Example: For a luks device with a 512-bit key, keyLength should be 64.
* Increase of the PBKDF2 iteration count per successful authentication added as the
parameter "iterationStep", defaults to 0.
Other changes:
* Add optional grace period before trying to find the yubikey, defaults to 2 seconds.
Full overview of the yubikey authentication process:
(1) Read $salt and $iterations from unencrypted device (UD).
(2) Calculate the $challenge from the $salt with a hash function.
Chosen instantiation: SHA-512($salt).
(3) Challenge the yubikey with the $challenge and receive the $response.
(4) Repeat three times:
(a) Prompt for the passphrase $k_user.
(b) Derive the key $k_luks for the luks device with a key derivation function from $k_user and $response.
Chosen instantiation: PBKDF2(HMAC-SHA-512, $k_user, $response, $iterations, keyLength).
(c) Try to open the luks device with $k_luks and escape loop (4) only on success.
(5) Proceed only if luks device was opened successfully, fail otherwise.
(6) Gather $new_salt from a cryptographically secure pseudorandom number generator
Chosen instantiation: /dev/random
(7) Calculate the $new_challenge from the $new_salt with the same hash function as (2).
(8) Challenge the yubikey with the $new_challenge and receive the $new_response.
(9) Derive the new key $new_k_luks for the luks device in the same manner as in (4) (b),
but with more iterations as given by iterationStep.
(10) Try to change the luks device's key $k_luks to $new_k_luks.
(11) If (10) was successful, write the $new_salt and the $new_iterations to the UD.
Note: $new_iterations = $iterations + iterationStep
Known (software) attack vectors:
* A MITM attack on the keyboard can recover $k_user. This, combined with a USB-MITM
attack on the yubikey for the $response (1) or the $new_response (2) will result in
(1) $k_luks being recovered,
(2) $new_k_luks being recovered.
* Any attacker with access to the RAM state of stage-1 at mid- or post-authentication
can recover $k_user, $k_luks, and $new_k_luks
* If an attacker has recovered $response or $new_response, he can perform a brute-force
attack on $k_user with it without the Yubikey needing to be present (using cryptsetup's
"luksOpen --verify-passphrase" oracle. He could even make a copy of the luks device's
luks header and run the brute-force attack without further access to the system.
* A USB-MITM attack on the yubikey will allow an attacker to attempt to brute-force
the yubikey's internal key ("shared secret") without it needing to be present anymore.
Credits:
* Florian Klien,
for the original concept and the reference implementation over at
https://github.com/flowolf/initramfs_ykfde
* Anthony Thysse,
for the reference implementation of accessing OpenSSL's PBKDF2 over at
http://www.ict.griffith.edu.au/anthony/software/pbkdf2.c
To be compatible with eb2f44c18c (Generate
/etc/passwd and /etc/group at build time). Without this you'll get this:
$ nixos-rebuild build
[...]
user-thrown exception: The option `users.extraGroups.unnamed-9.1.gid' is used but not defined.
