According to the MySQL manual, this is a perfectly legal way of
shutting down the server. The shutdown logs also looks fine:
systemd[1]: Stopping MySQL Server...
mysqld[5114]: 140319 8:36:12 [Note] /nix/store/sc26mz82k97mbpx3d1abzn3rrbd155ws-mariadb-10.0.8/bin/mysqld: Normal shutdown
mysqld[5114]: 140319 8:36:12 [Note] Event Scheduler: Purging the queue. 0 events
mysqld[5114]: 140319 8:36:12 [Note] InnoDB: FTS optimize thread exiting.
mysqld[5114]: 140319 8:36:12 [Note] InnoDB: Starting shutdown...
mysqld[5114]: 140319 8:36:14 [Note] InnoDB: Shutdown completed; log sequence number 1619078
mysqld[5114]: 140319 8:36:14 [Note] /nix/store/sc26mz82k97mbpx3d1abzn3rrbd155ws-mariadb-10.0.8/bin/mysqld: Shutdown complete
systemd[1]: Stopped MySQL Server.
For example, the following sets up a container named ‘foo’. The
container will have a single network interface eth0, with IP address
10.231.136.2. The host will have an interface c-foo with IP address
10.231.136.1.
systemd.containers.foo =
{ privateNetwork = true;
hostAddress = "10.231.136.1";
localAddress = "10.231.136.2";
config =
{ services.openssh.enable = true; };
};
With ‘privateNetwork = true’, the container has the CAP_NET_ADMIN
capability, allowing it to do arbitrary network configuration, such as
setting up firewall rules. This is secure because it cannot touch the
interfaces of the host.
The helper program ‘run-in-netns’ is needed at the moment because ‘ip
netns exec’ doesn't quite do the right thing (it remounts /sys without
bind-mounting the original /sys/fs/cgroups).
These are stored on the host in
/nix/var/nix/{profiles,gcroots}/per-container/<container-name> to
ensure that container profiles/roots are not garbage-collected.
This has the unintended side-effect of restarting httpd every time we
run switch-to-configuration, even if httpd hasn't changed (because
we're doing a "stop keys.target" now). So use a "Wants" dependency
instead.
On the host, you can run
$ socat unix:<path-to-container>/var/lib/login.socket -,echo=0,raw
to get a login prompt. So this allows logging in even if the
container has no SSH access enabled.
You can also do
$ socat unix:<path-to-container>/var/lib/root-shell.socket -
to get a plain root shell. (This socket is only accessible by root,
obviously.) This makes it easy to execute commands in the container,
e.g.
$ echo reboot | socat unix:<path-to-container>/var/lib/root-shell.socket -
This reverts commit b792394119.
Starting the manual on tty8 was intended as a convenience during
installation, not as a general purpose thing. In fact, given that w3m
runs as root, this is highly insecure!
This module adds the security.duosec attributes, which you can use to
enable simple two-factor authentication for NixOS logins.
The module currently provides PAM and SSH support, although the PAM unix
system configuration isn't automatically dealt with (although the
configuration is automatically built).
Enabling it is as easy as saying:
security.duosec.ssh.enable = true;
security.duosec.ikey = "XXXXXXXX...";
security.duosec.skey = "XXXXXXXX...";
security.duosec.host = "api-XXXXXXX.duosecurity.com";
security.duosec.group = "duosec";
which will enforce two-factor authentication for SSH logins for users in
the 'duosec' group.
This requires uid/gid support in the environment.etc module.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This has the nice side-effect of making gpsd actually run!
Old behaviour (debugLevel=2):
systemd[1]: gpsd.service holdoff time over, scheduling restart.
systemd[1]: Stopping GPSD daemon...
systemd[1]: Starting GPSD daemon...
systemd[1]: gpsd.service start request repeated too quickly, refusing to start.
systemd[1]: Failed to start GPSD daemon.
systemd[1]: Unit gpsd.service entered failed state.
New behaviour (debugLevel=2):
gpsd[945]: gpsd: launching (Version 2.95)
systemd[1]: Started GPSD daemon.
gpsd[945]: gpsd: listening on port 2947
gpsd[945]: gpsd: running with effective group ID 27
gpsd[945]: gpsd: running with effective user ID 23
gpsd[945]: gpsd: stashing device /dev/ttyUSB0 at slot 0
Uses standard NixOS user config merging.
Work in progress: The slave config does not actually start the slave agent. This just configures a
jenkins user if required. Bare minimum to enable a nice jenkins SSH slave.
By default the jenkins server is executed under the user "jenkins". Which can be configured using
users.jenkins.* options. If a different user is requested by changing services.jenkins.user then
none of the users.jenkins options apply.
This patch does not include jenkins slave configuration. Some config options will probably change
when this is implemented.
Aspects like the user and environment are typically identical between slave and master. The service
configs are different. The design is for users.jenkins to cover the shared aspects while
services.jenkins and services.jenkins-slave cover the master and slave specific aspects,
respectively.
Another option would be to place everything under services.jenkins and have a config that selects
master vs slave.
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.
Currently very basic gnome-shell launches on my laptop. Quite some
services won't start yet, most notable is gnome-control-center.
GTK3 apps still don't have theming applied and for example launching
chromium results in horrible red windows.
This is a rather large commit that switches user/group creation from using
useradd/groupadd on activation to just generating the contents of /etc/passwd
and /etc/group, and then on activation merging the generated files with the
files that exist in the system. This makes the user activation process much
cleaner, in my opinion.
The users.extraUsers.<user>.uid and users.extraGroups.<group>.gid must all be
properly defined (if <user>.createUser is true, which it is by default). My
pull request adds a lot of uids/gids to config.ids to solve this problem for
existing nixos services, but there might be configurations that break because
this change. However, this will be discovered during the build.
Option changes introduced by this commit:
* Remove the options <user>.isSystemUser and <user>.isAlias since
they don't make sense when generating /etc/passwd statically.
* Add <group>.members as a complement to <user>.extraGroups.
* Add <user>.passwordFile for setting a user's password from an encrypted
(shadow-style) file.
* Add users.mutableUsers which is true by default. This means you can keep
managing your users as previously, by using useradd/groupadd manually. This is
accomplished by merging the generated passwd/group file with the existing files
in /etc on system activation. The merging of the files is simplistic. It just
looks at the user/group names. If a user/group exists both on the system and
in the generated files, the system entry will be kept un-changed and the
generated entries will be ignored. The merging itself is performed with the
help of vipw/vigr to properly lock the account files during edit.
If mutableUsers is set to false, the generated passwd and group files will not
be merged with the system files on activation. Instead they will simply replace
the system files, and overwrite any changes done on the running system. The
same logic holds for user password, if the <user>.password or
<user>.passwordFile options are used. If mutableUsers is false, password will
simply be replaced on activation. If true, the initial user passwords will be
set according to the configuration, but existing passwords will not be touched.
I have tested this on a couple of different systems and it seems to work fine
so far. If you think this is a good idea, please test it. This way of adding
local users has been discussed in issue #103 (and this commit solves that
issue).
Rationale:
* The main reason for choosing to implement the PBA in accordance
with the Yubico documentation was to prevent a MITM-USB-attack
successfully recovering the new LUKS key.
* However, a MITM-USB-attacker can read user id and password when
they were entered for PBA, which allows him to recover the new
challenge after the PBA is complete, with which he can challenge
the Yubikey, decrypt the new AES blob and recover the LUKS key.
* Additionally, since the Yubikey shared secret is stored in the
same AES blob, after such an attack not only is the LUKS device
compromised, the Yubikey is as well, since the shared secret
has also been recovered by the attacker.
* Furthermore, with this method an attacker could also bruteforce
the AES blob, if he has access to the unencrypted device, which
would again compromise the Yubikey, should he be successful.
* Finally, with this method, once the LUKS key has been recovered
once, the encryption is permanently broken, while with the previous
system, the LUKS key itself it changed at every successful boot,
so recovering it once will not necessarily result in a permanent
breakage and will also not compromise the Yubikey itself (since
its secret is never stored anywhere but on the Yubikey itself).
Summary:
The current implementation opens up up vulnerability to brute-forcing
the AES blob, while retaining the current MITM-USB attack, additionally
making the consequences of this attack permanent and extending it to
the Yubikey itself.
switch-to-configuration.pl is currently hard-coded to assume that if a
unit is in the "auto-restart" state that something has gone wrong, but
this is not strictly true. For example, I run offlineimap as a oneshot
service restarting itself every minute (on success). NixOS currently
thinks that offlineimap has failed to start as it enters the
auto-restart state, because it doesn't consider why the unit failed.
This commit changes switch-to-configuration.pl to inspect the full
status of a unit in auto-restart state, and now only considers it failed
if the ExecMainStatus is non-zero.
[Bjørn Forsman <bjorn.forsman@gmail.com>:
- use types.lines instead of types.string. The former joins strings
with "\n" and the latter with "" (and is deprecated).
]
This is achieved by having multiple lines per storage file, one for each user (if the feature is enabled); each of these
lines has the same format as would be the case for the userless authentication, except that they are prepended with a
SHA-512 of the user's id.
IIUC, <nixos> is going to be deprecated someday in the future, and as
most of those references are already replaced I guess it's safe to
replace it here as well, as it is only relevant on new/updated
installations.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
'YubiKey Integration for Full Disk Encryption Pre-Boot Authentication (Copyright) Yubico, 2011 Version: 1.1'.
Used binaries:
* uuidgen - for generation of random sequence numbers
* ykchalresp - for challenging a Yubikey
* ykinfo - to check if a Yubikey is plugged in at boot (fallback to passphrase authentication otherwise)
* openssl - for calculation of SHA-1, HMAC-SHA-1, as well as AES-256-CTR (de/en)cryption
Main differences to the specification mentioned above:
* No user management (yet), only one password+yubikey per LUKS device
* SHA-512 instead of CRC-16 for checksum
Main differences to the previous implementation:
* Instead of changing the key slot of the LUKS device each boot,
the actual key for the LUKS device will be encrypted itself
* Since the response for the new challenge is now calculated
locally with openssl, the MITM-USB-attack with which previously
an attacker could obtain the new response (that was used as the new
encryption key for the LUKS device) by listening to the
Yubikey has ideally become useless (as long as uuidgen can
successfuly generate new random sequence numbers).
Remarks:
* This is not downwards compatible to the previous implementation
This will allow overriding package-provided units, or overriding only a
specific instance of a unit template.
Signed-off-by: Shea Levy <shea@shealevy.com>
