MinBZK/DAWO-NixOS

Fork 0

Fully declarative users with encrypted passwords (opt-in) #9

New issue

Open

opened 2026-06-18 08:37:04 +00:00 by bram.buijs · 2 comments

bram.buijs commented

2026-06-18 08:37:04 +00:00

Collaborator

What's missing

users-dawo today uses initialHashedPassword, i.e. the password hash sits in
a .nix file and ends up world-readable in the Nix store, and mutableUsers
is left at its default so accounts can drift at runtime (useradd/passwd on
the device). For a government workstation you want users fully as code, no
drift, and password material that isn't readable in the store.

Proposal

An opt-in users-hardened module that sets mutableUsers = false (nothing
outside git), plus a documented per-user inventory pattern:

modules/users/<name>.nix, one file per user (the inventory), like the
existing users-dawo
a host imports the users that belong on it; the import list is the
machine->user mapping
passwords via agenix hashedPasswordFile instead of a hash in git, agenix is
already wired through the environment module

docs/users.md documents the add-a-user flow, the agenix step
(mkpasswd -m yescrypt -> agenix -e), the admin/sudo pattern (wheel, plus
nixos-pam-u2f for strong auth), and the SSH-only superadmin pattern.

Norm: BIO access management + gitops.

Note

Enabling users-hardened is lockout-risk: with mutableUsers = false every
login user needs a hashedPasswordFile/hashedPassword (not
initialHashedPassword). Migrate first, test on a canary, keep a recovery path.
That's why it's opt-in and users-dawo is left as-is for now.

Question

Welcome upstream? And is users-hardened the right name / shape for the
mutableUsers-false switch?

## What's missing `users-dawo` today uses `initialHashedPassword`, i.e. the password hash sits in a `.nix` file and ends up world-readable in the Nix store, and `mutableUsers` is left at its default so accounts can drift at runtime (`useradd`/`passwd` on the device). For a government workstation you want users fully as code, no drift, and password material that isn't readable in the store. ## Proposal An opt-in `users-hardened` module that sets `mutableUsers = false` (nothing outside git), plus a documented per-user inventory pattern: - `modules/users/<name>.nix`, one file per user (the inventory), like the existing `users-dawo` - a host imports the users that belong on it; the import list *is* the machine->user mapping - passwords via agenix `hashedPasswordFile` instead of a hash in git, agenix is already wired through the environment module `docs/users.md` documents the add-a-user flow, the agenix step (`mkpasswd -m yescrypt` -> `agenix -e`), the admin/sudo pattern (`wheel`, plus `nixos-pam-u2f` for strong auth), and the SSH-only superadmin pattern. Norm: BIO access management + gitops. ## Note Enabling `users-hardened` is lockout-risk: with `mutableUsers = false` every login user needs a `hashedPasswordFile`/`hashedPassword` (not `initialHashedPassword`). Migrate first, test on a canary, keep a recovery path. That's why it's opt-in and `users-dawo` is left as-is for now. ## Question Welcome upstream? And is `users-hardened` the right name / shape for the mutableUsers-false switch?

bram.buijs referenced this issue

2026-06-18 08:37:04 +00:00

WIP: feat: declarative user management #13

bram.buijs referenced this issue

2026-06-18 08:37:05 +00:00

feat: overheid baseline (hardening opt-in, users, T495s host, 26.05 pin) #7

rutger.putter commented

2026-06-18 10:45:34 +00:00

Collaborator

It's a great suggestion to be sure. I'd like to see some options in this blocks repo:

Example users like we have now to get started and testing
Standardized config for LDAP / SSSD connections
Maybe more options to connect to other user databases as well

It's a great suggestion to be sure. I'd like to see some options in this blocks repo: - Example users like we have now to get started and testing - Standardized config for LDAP / SSSD connections - Maybe more options to connect to other user databases as well

bram.buijs commented

2026-06-18 12:36:13 +00:00

Author

Collaborator

Thanks, for now LDAP and SSSD seem org specific. What you want to use is greatly dependent on the orgs (IdP, IAM stack).

Difficult to make generic. What we could do is multiple modules for popular sign in options? (more maintenance on our end)

Example users I'll add.

Thanks, for now LDAP and SSSD seem org specific. What you want to use is greatly dependent on the orgs (IdP, IAM stack). Difficult to make generic. What we could do is multiple modules for popular sign in options? (more maintenance on our end) Example users I'll add.

rutger.putter added the

Kind/Feature

Kind/Enhancement

Kind/Security

labels

2026-06-22 09:19:21 +00:00

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

MinBZK/DAWO-NixOS#9

No description provided.

Rows
Columns