New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LUKS password no-longer prompted on boot #1962

Closed
jpap opened this Issue May 11, 2017 · 6 comments

Comments

Projects
None yet
4 participants
@jpap

jpap commented May 11, 2017

Issue Report

Bug

I just manually upgraded a box from 1235.12.0 to 1353.7.0 and the LUKS password prompt for the root filesystem was no-longer being issued to the console on boot.

Extracting the initramfs on the 1353.7.0 vmlinuz image, it looks like:

  • The systemd-cryptsetup and systemd-cryptsetup-generator binaries are no-longer being included.
  • The cryptsetup.target has been removed.
  • The systemd-ask-password-console.path has been removed.

If I patch the 1353.7.0 initramfs with the above from 1235.12.0 (plus the old libsystemd-shared-231.so so the above cryptsetup binaries execute), the password prompt re-appears on boot.

Can we get the above systemd support back into the initramfs?

Container Linux Version

$ cat /etc/os-release
NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1353.7.0
VERSION_ID=1353.7.0
BUILD_ID=2017-04-26-2154
PRETTY_NAME="Container Linux by CoreOS 1353.7.0 (Ladybug)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://issues.coreos.com"

Environment

Bare metal server.

Expected Behavior

The LUKS password is prompted on boot from within the initramfs.

Actual Behavior

No prompt; dracut eventually times out and dumps the console on an emergency prompt.

Reproduction Steps

  1. Encrypt the root partition using LUKS.
  2. Boot.
  3. Try steps with 1235.12.0 (prompt -- works) and 1353.7.0 (no prompt -- broken).
@euank

This comment has been minimized.

Show comment
Hide comment
@euank

euank May 11, 2017

Contributor

AFAIK we've yet to intentionally support LUKS encrypting root, so the fact that it did work was merely a happy accident.

We're still working out proper support (more discussion #1687).

Since we're going to be shipping those tools in the initrd eventually regardless, it makes sense to add them back, but we might not have proper tests for this until we have a supported/documented approach using ignition.

cc @dm0-, it seems likely this changed as part of the v233 update at a guess.

Contributor

euank commented May 11, 2017

AFAIK we've yet to intentionally support LUKS encrypting root, so the fact that it did work was merely a happy accident.

We're still working out proper support (more discussion #1687).

Since we're going to be shipping those tools in the initrd eventually regardless, it makes sense to add them back, but we might not have proper tests for this until we have a supported/documented approach using ignition.

cc @dm0-, it seems likely this changed as part of the v233 update at a guess.

@jpap

This comment has been minimized.

Show comment
Hide comment
@jpap

jpap May 11, 2017

I'm happy to have unofficial support until it is formalized. I've been making good use of LUKS for full-disk encryption since late 2016. I'm also happy to manually test it for you in the meantime, since I'm using it anyway.

To remotely supply the unlock secret on boot, I'm using a dropbear sshd. I do this by patching your initramfs for each CoreOS update, which is a pain, but I often have to rebuild kernel drivers (modules) on some upgrades anyway; this process is semi-automated.

Separately, would you be open to adding a dropbear sshd to the initramfs? I'm happy to open a new issue. In my setup, dropbear only activates when there exists a rd.luks.uuid kernel cmdline argument (added by Grub automatically) and when a dropbear.conf configuration file is present on the OEM partition. (It can also be explicitly disabled though rd.luks=false.) The dropbear {server, authorized-user} keys are supplied from the same OEM partition in a dropbear/ folder.

jpap commented May 11, 2017

I'm happy to have unofficial support until it is formalized. I've been making good use of LUKS for full-disk encryption since late 2016. I'm also happy to manually test it for you in the meantime, since I'm using it anyway.

To remotely supply the unlock secret on boot, I'm using a dropbear sshd. I do this by patching your initramfs for each CoreOS update, which is a pain, but I often have to rebuild kernel drivers (modules) on some upgrades anyway; this process is semi-automated.

Separately, would you be open to adding a dropbear sshd to the initramfs? I'm happy to open a new issue. In my setup, dropbear only activates when there exists a rd.luks.uuid kernel cmdline argument (added by Grub automatically) and when a dropbear.conf configuration file is present on the OEM partition. (It can also be explicitly disabled though rd.luks=false.) The dropbear {server, authorized-user} keys are supplied from the same OEM partition in a dropbear/ folder.

@euank

This comment has been minimized.

Show comment
Hide comment
@euank

euank May 26, 2017

Contributor

I'm wary of including dropbear. We're already pretty sure we'll want luks in the future, but it's less likely that we'll want dropbear in the long term.

Contributor

euank commented May 26, 2017

I'm wary of including dropbear. We're already pretty sure we'll want luks in the future, but it's less likely that we'll want dropbear in the long term.

@jpap

This comment has been minimized.

Show comment
Hide comment
@jpap

jpap May 26, 2017

I agree with that -- my approach was a pragmatic one. At this stage I'm not expecting dropbear support in the CoreOS initramfs. But it would be appreciated if you could restore cryptsetup in the meantime.

I can imagine that you'll eventually need some kind of client and daemon pair, with the initramfs acting as a client perhaps leading to a cleaner architecture. The initramfs connects on startup to a centralized daemon "waiting room" for their LUKS key. That key is provided either automatically, or manually on operator approval. You could use TLS mutual auth with client keys stored on the OEM partition; the server-side would need to support a CRL in case the CoreOS machine is stolen or compromised. Or, perhaps less desirable, we could use some kind of hardware ID in lieu of a client cert.

What I'm doing with dropbear/SSH is actually very similar to the above, where SSH keys are used in place of TLS mutual auth, and the initramfs is the daemon, not the client. The client is my terminal, where I manually SSH into the CoreOS machine (initramfs; via dropbear) after a reboot.

I'm not aware of anything we could use off-the-shelf. If I find any time, I'll have a stab at writing something simple -- would you be interested in that approach at all?

jpap commented May 26, 2017

I agree with that -- my approach was a pragmatic one. At this stage I'm not expecting dropbear support in the CoreOS initramfs. But it would be appreciated if you could restore cryptsetup in the meantime.

I can imagine that you'll eventually need some kind of client and daemon pair, with the initramfs acting as a client perhaps leading to a cleaner architecture. The initramfs connects on startup to a centralized daemon "waiting room" for their LUKS key. That key is provided either automatically, or manually on operator approval. You could use TLS mutual auth with client keys stored on the OEM partition; the server-side would need to support a CRL in case the CoreOS machine is stolen or compromised. Or, perhaps less desirable, we could use some kind of hardware ID in lieu of a client cert.

What I'm doing with dropbear/SSH is actually very similar to the above, where SSH keys are used in place of TLS mutual auth, and the initramfs is the daemon, not the client. The client is my terminal, where I manually SSH into the CoreOS machine (initramfs; via dropbear) after a reboot.

I'm not aware of anything we could use off-the-shelf. If I find any time, I'll have a stab at writing something simple -- would you be interested in that approach at all?

@bgilbert

This comment has been minimized.

Show comment
Hide comment
@bgilbert

bgilbert Jun 8, 2017

Member

cryptsetup should be restored in 1437.0.0. I'll close this issue; design discussions for LUKS support should go in #1687. Thanks for the report!

Member

bgilbert commented Jun 8, 2017

cryptsetup should be restored in 1437.0.0. I'll close this issue; design discussions for LUKS support should go in #1687. Thanks for the report!

@bgilbert bgilbert closed this Jun 8, 2017

@lals1

This comment has been minimized.

Show comment
Hide comment
@lals1

lals1 Aug 31, 2017

@jpap Hi John, would you be kind enough to share details on how did you encrypt root filesystem using LUKS in CoreOS 1235.12.0? Would be a great help.

lals1 commented Aug 31, 2017

@jpap Hi John, would you be kind enough to share details on how did you encrypt root filesystem using LUKS in CoreOS 1235.12.0? Would be a great help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment