GitLab (and few others) use nix store to keep passwords

[spinus]

Issue description

As far as I understand, all of those settings

nixpkgs/nixos/modules/services/misc/gitlab.nix

Line 335 in e330807

secrets.db = mkOption {

end up in nix store.

Steps to reproduce

1. Enable gitlab service in /etc/nixos/configuration.nix (services.gitlab.enable=true)
2. Fill missing values to keep gitlab happy

    services.gitlab.databasePassword = "qqq";
    services.gitlab.secrets.secret ="Xxx";
    services.gitlab.secrets.otp ="Xxx";
    services.gitlab.secrets.db ="Xxx";

1. cry

Should we have clear way to handle that?
Personally for own services I use paths to files with secrets (deployed usually with nixops, so it integrates nicely).

Should choose some clear way to define secrets like that and update the docs?

Technical details

• System: since 2014
• Nix version: not relevant
• Nixpkgs version: since 2014

[knedlsepp]

You might want to read through this: NixOS/nix#8

[spinus]

@knedlsepp I know this, but it has 4 years, and it can take another while before this will be implemented. I'm interested more about doing something now.
Using password/secret files could be that simple temporary solution.

[Jookia]

I use paths to secrets at the moment, which works for containers too. Interestingly, there's no way to add files to the initramfs without putting it in store. Perhaps a topic for another issue, but a hook to copy stuff in to an initramfs when installing the bootloader seems like a good idea.

[jokogr]

@spinus and @Jookia could you make an example of password / secret files for this particular case?

[spinus]

@jokogr https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/config/users-groups.nix#L203

[arianvp]

I am working on a patch to fix this for gitlab. I use nixops to deploy https://arianvp.me/ and because I think it's good for people as a learning resource, the entire thing is out in the open on github http://github.com/arianvp/arianvp.me

I use nixops secret management to provision secrets, as can seen here: https://github.com/arianvp/arianvp.me/blob/master/arianvp.me/services/nginx.nix#L15

However, currently gitlab module does not support reading secrets from file, but only from the nix expressions. Of course, all my nix expressions are open source, and I should not store secrets in git.

So I'm working on a patch that makes it possible to just specify the location of gitlabs secrets.yml instead of letting this be built into the nix store as I think this is a bad design choice.

[arianvp]

This is a breaking change though, as it would break existing gitlab installs. Howabouts would I communicate that clearly?

[spinus]

@arianvp there is a function in nix which inform people about deprecated stuff. I'm not sure if there are any rules for nixos to keep compatibility between versions.

Less intrusive way of doing that would be to support two ways for one release and show deprecation message to people using function I mentioned (IMHO, probably someone from the core team could comment how to do that better).

[fpletz]

@arianvp Looks interesting. Ping me if you need help.

[mguentner]

More rather interesting modules that leak a lot of information to the 0444/0555 /nix/store 🙈 🙉 🙊

• cjdns (passwords):
  https://github.com/NixOS/nixpkgs/blob/e5cefadef7995b3eafacaf6f1f9099da0f7ccf79/nixos/modules/services/networking/cjdns.nix
  (also, ref nixos.cjdns: allow multiple cjdns networks and multiple UDP/ETH interfaces per network #22637)
• wireguard (it even includes the private key 👿):
  

  nixpkgs/nixos/modules/services/networking/wireguard.nix

  Line 24 in e5cefad

  privateKey = mkOption {

• mysql (root password)
  

  nixpkgs/nixos/modules/services/databases/mysql.nix

  Line 117 in e5cefad

  # FIXME: remove this option; it's a really bad idea.

[joachifm]

@mguentner cjdns is actually an example of a service that does not leak lots of secrets into the store ... it could easily be extended to also read the list of authorized password hashes at run-time as well, if reversing them was considered trivial (if you can demonstrate that, please file a bug).

(EDIT: I certainly hope they are hashes, at any rate, if not that'd be kind of awful ...)
(EDIT2: I was wrong, sorry)

[ghost]

@joachifm

cjdns is actually an example of a service that does not leak lots of secrets into the store

cjdns module does write authorizedPasswords and password options into nix store as world readable plain text. These are no hashes but actual passwords. If somebody gets hold of the password, he gets access to that network.

it could easily be extended to also read the list of authorized password hashes at run-time as well, if reversing them was considered trivial (if you can demonstrate that, please file a bug).

Why do you think that those passwords are hashes?

[joachifm]

@tohl I had assumed they were ... obviously I was wrong :)

[mguentner]

NixOS is great but the filesystem design is inherently flawed. It completely undermines any security gained by having ACLs on filesystem nodes. It is doing that while making dangerous assumptions (i.e. all my config files can be public - 444/555!) and because at the time of writing (the idea of Nix dates back to 2003!), Linux had no other means of deduplicating content other than symlinks.

In the long run filesystems that support deduplication should be used (ZFS, btrfs, XFS, have I missed something?) or even writing something like a systemFS/NixFS that manages ACLs by user/pid/environment/context (think NSALinux with a fixed state) is thinkable. By moving high-value information out of the store, not all problems are solved yet. Since, by reading the nix-store alone, you know the whole system config (maybe sans the passwords/keys), plus the environment (other machines, routings, IPs). However, this is not an easy task since it challenges one of the core elements of Nix(OS): the Store...and thus a lot of other concepts should be checked before hacking a intermediate solution.

Although NixOS relies currently on systemd, security should not completely forgotten.

---

@joachifm Great. Thanks for creating an issue.

[nlewo]

FYI, there is also an attempt to manage secrets in the openstack modules https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/virtualisation/openstack/common.nix#L24.
Basically, we let the user choose how the password is stored (currently in the store or in a file) and we provide helpers to replace them in configuration files at runtime.

[florianjacob]

„Provide options for storing secrets outside the Nix store:“ #24288 collects all affected packages, tracks progress and provides information on how to do the transition for storing secrets outside of the nix store.

[domenkozar]

For gitlab the PR that fixes this is in https://github.com/NixOS/nixpkgs/pull/31358/files and general issue for going on is in #24288

Closing.