Skip to content
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

Support wrapping a file system under LUKS #54494

Closed
wants to merge 1 commit into from

Conversation

adrianparvino
Copy link
Contributor

@adrianparvino adrianparvino commented Jan 23, 2019

Motivation for this change

Produces a luks-encrypted image to be mounted by #53600

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Assured whether relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@lheckemann
Copy link
Member

Oh, one thing to note: I'm not 100% sure, but I strongly suspect that having the filesystem with the LUKS header where the passphrase is simply PASSPHRASE will allow accessing the encrypted data even after the passphrase has been changed, simply by using the old header. This is probably worth a mention in the PR.

adrianparvino added a commit to adrianparvino/NixOSEncryptedLiveCD that referenced this pull request Jan 29, 2019
A brief conversation on ##nixos@irc.freenode.net and
NixOS/nixpkgs#54494 (comment)
pointed out that having a temporary passphrase is insecure.

This commit allows two things:
a) For the security-critical people to call wrap-luks outside of Nix,
   this requires additional machinery to feed the output back into Nix; and
b) Using .overrideDerivation on the derivation to change the default passphrase.
@adrianparvino
Copy link
Contributor Author

@lheckemann Thanks! I'll get back to this PR soon.
On another repo[1], I extracted the shell script from wrap-luks.nix, allowing people to call it without Nix, albeit requiring root(though can be circumvented with qemu, such as what the patch does from the start.); alternatively, I made it so that you can override the passphrase using .overrideDerivation.

[1] adrianparvino/NixOSEncryptedLiveCD@a57c778

@lheckemann
Copy link
Member

Using overrideDerivation isn't any more secure than using a temporary passphrase, as anyone with access to the store can just get the passphrase from the drv. It's not critically broken, it just needs to be clear that this is not safe to use on stores which untrusted parties have access to.

@mmahut
Copy link
Member

mmahut commented Aug 18, 2019

Are there any updates on this pull request, please?

@lheckemann
Copy link
Member

@adrianparvino would you be opposed to closing this? As we've discussed (also on IRC), there's not really a way to make this work really securely and usefully.

@adrianparvino
Copy link
Contributor Author

adrianparvino commented Aug 20, 2019 via email

@mmahut mmahut closed this Aug 20, 2019
@tim-tx
Copy link
Contributor

tim-tx commented Aug 5, 2021

I'm not sure I fully understand the original intent, but what about building an image with some encrypted partition where the passphrase is supplied with deployment.keys? Then there's no initial password that is known just from looking at the source configuration, and so the LUKS header in the store is not a threat. Or you could use some other strategy from this list: https://nixos.wiki/wiki/Comparison_of_secret_managing_schemes

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

Successfully merging this pull request may close these issues.

None yet

5 participants