NixOS Service Configuration via `flake.nix`

[brynblack]

Specification

The below specification is with regards to secret zero problem, however the actual PR solving this is just introducing the service configuration. For now, the "secret zero" of PK which is the root password, is just expected to exist in the home directory.

It seems we are running into the secret zero problem with regard to the new Polykey Agent nix service. When running pk agent start for the first time, it is required that a password is supplied to initialise the agent. However that password needs to be managed by something, and appropriately stored somewhere. Currently, the service will look for a password file under /root/.local/share/pass, but this is unoptimal for our situation. Keeping it in a place which is more secure and standardised will be ideal. Possibly /run/credentials or /run/keys.

My proposal is that there are a few solutions to solving this problem.

• Systemd supports the configuration directive EnvironmentFile which lets the service pull environment variables from a specified file. We could then in the service configuration use that environment variable in the setup script; or
• We set the Environment directive inside the Systemd service to pull from a given environment variable accessible to the system, but not from a file. Perhaps we inject the password somehow when building the system, but with flakes that doesn't seem likely; or
• We use systemd-ask-password which lets the user enter a password to be used in the service. This could be a simple way of specifying it safely.

Additionally, the Polykey Agent normally outputs a recovery code upon the initial setup of the agent. This will need to also be stored somewhere safe. A new CLI flag will need to be created to output the recovery codes to a specified directory (something similar to -pf).

@tegefaulkes @amydevs

Tasks

1. A flag inside of Polykey-CLI will need to be added to allow the secret output directory to change.
2. The service will need to be configured to use one of the solutions above and use the password in the service.
3. Documentation will need to be written up on how to set up the agent with the given solution.

[brynblack]

Ah it seems there are also additional tools to go about this. See https://systemd.io/CREDENTIALS/

[tegefaulkes]

If we can set env variables for a service to use then that would be the best option. Ideally we only need to configure a password and recovery code via nix. It's too clunky to require adding a file at whatever location just to have the service work. But we can't specify the secret inside the nix config. However I think it would be reasonable to configure it via nix to set PK_PASSWORD and PK_RECOVERY_CODE from a file you specify.

[CMCDragonkai]

Have a read of the README.md of https://gitlab.com/MatrixAI/Engineering/Infrastructure/Tetra - search for "credentials", all the info about how secrets are configured for Nix services was the case for mimir and similar services.

[brynblack]

With the exporting the recovery code part, we can probably do a lot of things here too. Namely:

• Feeding the code back into a file in /run/keys/...
• Having a configuration entry in the module to change the directory to output it to
• Outputting the code during the rebuilding of the Nix configuration (the user would then save this?)

The thing though is that all of these options depend on a feature in Polykey-CLI to export the key. It should probably be only a file based output, as that can be parsed later and used for the other methods. So this is needed. Maybe an option like -rf? The typical output from the service would need to be disabled though to protect the journal logs from showing the recovery code.

[brynblack]

* Feeding the code back into a file in `/run/keys/...`

This option could work as /run/keys is already R/W protected, and only root and @wheel can access it. Also means we won't have to worry about extra logic.

* Having a configuration entry in the module to change the directory to output it to

With this option it gives the user much more flexibility, but we need to remember that this is a one time thing and that the file that is outputted will probably be readable in the user space, so perhaps a warning or notice should be issued to the user for them to protect it appropriately.

* Outputting the code during the rebuilding of the Nix configuration (the user would then save this?)

Probably the most direct option, we could just print out the value when the rebuild is issued. Problem is the user might not see it as the flake output generally hides this under an abstraction, and is only accessible when doing --verbose. Also could be visible in system logs. So I'm not sure.

[CMCDragonkai]

Firstly the question is what to do about stdout when running the agent program. Given that it assumed a secure terminal, but now it's part of a service + it's better to instead allow the user to also supply the recovery code instead of a password. Alternatively we can redirect the output of stdout to a secure location. 27 Feb 2024 20:18:49 Brynley Llewellyn-Roux ***@***.***>:

…

** Feeding the code back into a file in `/run/keys/...` * This option could work as */run/keys* is already R/W protected, and only *root* and ***@***.**** can access it. Also means we won't have to worry about extra logic. ** Having a configuration entry in the module to change the directory to output it to * With this option it gives the user much more flexibility, but we need to remember that this is a one time thing and that the file that is outputted will probably be readable in the user space, so perhaps a warning or notice should be issued to the user for them to protect it appropriately. ** Outputting the code during the rebuilding of the Nix configuration (the user would then save this?) * Probably the most direct option, we could just print out the value when the rebuild is issued. Problem is the user might not see it as the flake output generally hides this under an abstraction, and is only accessible when doing *--verbose*. Also could be visible in system logs. So I'm not sure. — Reply to this email directly, view it on GitHub[#143 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AAE4OHMH36QVKG4FU2Y2IPTYV2OZRAVCNFSM6AAAAABD5BXXYCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRYGEZDGOJRGA]. You are receiving this because you commented. [Tracking image][https://github.com/notifications/beacon/AAE4OHNWJLIVJZIZXK2Z7E3YV2OZRA5CNFSM6AAAAABD5BXXYCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTVJ4YAM.gif]

[CMCDragonkai]

Needs to be categorised under the issue 17.

[CMCDragonkai]

I am making a driveby comment here.

But I believe you should not expect the existence of /root when creating a system level service in NixOS, or any specific system.

I think that is only for programs.*. There's a difference between services.* vs programs.*, and I have a feeling that program modules can do things in /root, but not services modules.

[CMCDragonkai]

Ok see: https://chat.openai.com/c/cba1fdba-4a58-402f-92d3-6bba5fa53777 in our team gpt. It does actually have something similar to what I'm saying above.

[CMCDragonkai]

This is the wrong place to discuss the secret zero problem. We should be discussing this in the orchestrator first (as it pertains to our platforms) - then in the nixpkgs repos.

[CMCDragonkai]

Based on the chatgpt discussion - I think this means we would distinguish 2 kinds of modules:

1. services.polykey - this would be a system level service of polykey-agent that is catered to the NixOS SYSTEM
2. programs.polykey - this would be configuration for users including root and non-root users

User-level systemd services is actually not available in NixOS. This is outside the domain of NixOS.