0040: Security defaults on Linux

Context

ADR 0015 promised a desktop that is safe without settings: nothing listening, updates found without asking, and privacy switches that say how far they reach. Its mechanisms (a packet filter, a base updater, encrypted home datasets) belonged to the base ADR 0016 replaced. The promise stands; this record states how the Linux system keeps it. Details and file lists: docs/modules/security.md.

Decision

• On from the first boot, each item reported from the running system by wol security [--json] (wol_core::security::status, crates/core/src/security.rs):
  • Firewall: nftables, /etc/wolos/nftables.conf (desktop/overlay/etc/wolos/nftables.conf), nftables.service enabled. Inbound and forwarded traffic is dropped except replies, loopback, ping, DHCP, IPv6 neighbour discovery and mDNS; outbound is allowed. wol firewall on|off|status changes it through wol-admind.
  • No remote login: sshd.service stays disabled until Sharing turns it on.
  • The log stays local: journald only; Privacy & Security reports a network syslog daemon (security::NETWORK_LOGGERS) as a problem.
  • Kernel hardening: files/usr/lib/sysctl.d/90-wolos.conf, one reason per line; security::HARDENING is the list Settings checks against /proc/sys.
• Updates: wolos-update-check.timer looks (hourly timer, at most one check per 20 h) and writes findings only; wolos-update-download.timer downloads once a day and installs nothing. Installing is asked for in Software Update, and a new release goes into the other btrfs root slot, so the running slot is the restore point (ADR 0016, docs/modules/security.md, Updates).
• App permissions say how they are enforced (security::Enforcement, one line of why per permission in security::PERMISSIONS):
  • Compositor: screen copy, cursor position and input capture are refused by static compositor rules (security::hypr_permissions, /usr/share/wolos/hypr/permissions.conf, first match wins). Only the system's own tools copy the screen directly (security::SCREENCOPY_SYSTEM); apps share the screen through the portal, which asks each time which screen or window. Screen capture is therefore never a grant in the consent file (consent::refusal). Compositor plugins load only from security::PLUGIN_DIR.
  • System: wold refuses a libwol service call (notifications, package changes and the other grants in consent::CAPABILITIES) unless /etc/wolos/consent.json (consent::FILE) holds the grant; it reads the file on every call (crates/api/src/portal.rs), so a change in Settings applies at once. The caller's identity comes from the kernel after the hello of ADR 0033; system package changes run in wold only after the person allowed them on screen (ADR 0034).
  • Advisory: camera, microphone, location, files outside home, virtual keyboards, clipboard history and the window list. A grant is recorded and shown to helpers that ask; an app that ignores it is not stopped, and Settings says so.
  • X11 apps share one trust domain per account: Xwayland admits only the signed-in account.
• Encrypted homes: a systemd-homed LUKS home per account (wol_core::home_crypt), opened by wol-login with the password it has just checked. Off by default until proven on a real install. Whole-disk encryption unlocks with the security chip, then the account's password, then the recovery key.

Consequences

no per-app sandbox yet: apps run as the account, so the advisory permissions stay advisory until a device-level mechanism exists (a per-app broker for the camera and microphone, or a sandbox around the app). Root daemons stay small: fixed argv lists, the allow-listed AdminAction set, peer identity from the kernel, each parsing only its own wire format. The firewall at boot, the compositor prompts and encrypted homes still need a check on real hardware (docs/modules/security.md, Needs hardware). Settings and wol security read the live system, so a drift between this record and the image shows up there first.