Hardening and extras

The base image is lean: only profiles-dawo-core (the mandatory BIO/NCSC baseline) is forced on. Everything below is opt-in. You enable a block on a host or in your org repo through its dawo.<block> option; you never edit the core.

The opt-in hardening tier

Import profiles-dawo-hardened to declare the opt-in blocks (this only makes the options available, nothing turns on by itself), then flip what you want:

imports = [ profiles-dawo-hardened ];

dawo.apparmor.enable = true;
dawo.gnomeHardening.enable = true;
dawo.gnomeHardening.options.idleLockSeconds = 300;

Available now:

• dawo.apparmor -- AppArmor mandatory access control. Can hit app sandboxes, so enable on a canary with proper profiles first.
• dawo.gnomeHardening -- locked GNOME dconf profile (automatic screen lock, privacy, lockdown). Only meaningful together with the GNOME desktop block.

Planned (next batch): dawo.pamU2f (FIDO2 login), dawo.pamOath (TOTP), egress-deny networking, a disk-encryption block.

Desktops

dawo.desktop.gnome.enable selects GNOME (GDM) as an alternative to the default desktop. A host picks one.

Features and apps

Add capabilities as blocks, not by hand-editing the base:

• Smartcard / PKI (e.g. PKIoverheid) -- enable pcscd and ship the middleware (opensc) plus the government CA bundle, so the browser and login can use a card. Planned as a dawo.smartcard / dawo.pkiOverheid block.
• YubiKey / FIDO2 -- dawo.pamU2f for FIDO2 login and sudo; pair with the smartcard block for PIV. Planned (next batch).
• App sets -- office, browser and org-specific apps belong in the consumer/org repo, not in the lean core. Expose them there as blocks too.

Rule of thumb

• Mandatory for every government device -> profiles-dawo-core (forced on).
• Risky, specialist, or a per-workplace choice -> an opt-in block here.
• Org branding, user accounts, or app sets -> the consuming org repo, not this core.