Another service definition question: Files containing secrets?

Another service definition question: Files containing secrets?

[Zack Weinberg]

The same slightly weird daemon I was talking about earlier expects to
find another file in /etc containing a piece of secret information - namely,
a token it will use to authenticate to a remote server.  This token does
not change in normal operation, and the most natural way to deal with it
would be to provide it as part of the service configuration.  (It cannot
be generated at activation time, the way SSH host keys are.)

The *problem* with this is that it appears there's no way to make a file
in the store not be world readable.

What's the best way to deal with this situation?

zw

Re: Another service definition question: Files containing secrets?

[Hartmut Goebel]

Hi,

Am 28.07.24 um 23:27 schrieb Zack Weinberg:
> The*problem*  with this is that it appears there's no way to make a file
> in the store not be world readable.
>
> What's the best way to deal with this situation?

I feel your pain! Several years ago already I started a nullmailer 
service for Guix - and never finished it for similar reasons. 
(nullmailer expects the password being part of the config file.)

I'm afraid, the only solution is to create a service which generates the 
config at boot time from a file containing the password and some 
template (or guile data structure). The password file would not be part 
of the Guix system definition. Anyhow I'm not aware of any example, sorry.

Please let me know if you implement something like this as I'd like to 
eventally finish the nullmailer service :-)

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          |h.goebel@crazy-compilers.com                |
|www.crazy-compilers.com  | compilers which you thought are impossible |

Re: Another service definition question: Files containing secrets?

[Marek Paśnikowski]

Hartmut Goebel <h.goebel@crazy-compilers.com> writes:

> Hi,
>
> Am 28.07.24 um 23:27 schrieb Zack Weinberg:
>> The*problem* with this is that it appears there's no way to make a
>> file in the store not be world readable.
>>
>> What's the best way to deal with this situation?
>
> I feel your pain! Several years ago already I started a nullmailer
> service for Guix - and never finished it for similar
> reasons. (nullmailer expects the password being part of the config
> file.)
>
> I'm afraid, the only solution is to create a service which generates
> the config at boot time from a file containing the password and some
> template (or guile data structure). The password file would not be
> part of the Guix system definition. Anyhow I'm not aware of any
> example, sorry.
>
> Please let me know if you implement something like this as I'd like to
> eventally finish the nullmailer service :-)

At the start of my server configuration I have the following lines:

(define smtpd-keys "/secrets/smtpd")
(define radicale-keys "/secrets/radicale/keys")
(define dovecot-keys "/secrets/dovecot")

These files have appropriately limited permissions and are not tracked
with any version control.  It is my responsibility to ensure the
integrity of this data.

The /etc directory is writable for root, so if a configuration file must
be in /etc , it can…? I wonder how that works with the system activation
now.  I am afraid that any undeclared files in /etc could get wiped on
system reconfigurations.

In the past I had attempted to maintain a file-based guix channel for
secrets, but it was not possible to easily reconcile the necessity of
declaring the channel as a dependency and having it on one system only.

Re: Another service definition question: Files containing secrets?

[Giacomo via]

Hello Zack,

I developed and currently use sops-guix, a reimplementation of sops-nix principles in Guix' terms [0]. Basically secrets never hit the disk in clear text, they are encrypted before including them in the Guix code and get decrypted at activation time, provided the right keys are present on the target machine.

While it is completely based on free software it is not in Guix mainline due to the comolexity of packaging SOPS' dependency graph. As soon as there's a SOPS package in Guix I plan to upstream the sops-secrets-service-type and sops-secret record.

HTH,

giacomo

[0]: https://github.com/fishinthecalculator/sops-guix