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.
Currently switch-to-configuration.pl uses system() calls to interact
with DBus. This can be error prone, especially when we are parsing
output that could change. In this commit, almost all calls to the
systemctl binary have been replaced with equivalent operations via DBus.
[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>
Includes configuration option for the threshold beneath which to refill
the entropy pool - defaults to 1024 bits as this is the number used in
other distro's existing service files I looked at.
With kmscon, it is now possible to have a system without X that still
needs the mesa setup in /run/opengl-driver
Signed-off-by: Shea Levy <shea@shealevy.com>
This required some changes to systemd unit handling:
* Add an option to specify that a unit is just a symlink
* Allow specified units to overwrite systemd-provided ones
* Have gettys.target require autovt@1.service instead of getty@1.service
Signed-off-by: Shea Levy <shea@shealevy.com>
Now that Java is happy with our /etc/localtime, there is no reason to
set $TZ anymore. (See 945849b86fe33474da569b307d7e5880877491b6, 279248f6c562eb88227d22b824c9324683980b96, 1b5e860f65607b4cc7de4b6b5db95460cf144526.)
Fixes#1463.
Some programs (notably the Java Runtime Environment) expect to be able
to extract the name of the time zone from the target of the
/etc/localtime symlink. That doesn't work if /etc/localtime is a
symlink to /etc/static/localtime. So make it a direct symlink.
