[PLAN 23] Zamknąć profile trust, bezpieczeństwo funkcjonalne i supply chain

[KeyffMS]

Cel

Zdefiniować i egzekwować granice bezpieczeństwa aplikacji przemysłowej, zaimplementować ProfileTrustPort, zweryfikować pakietowane profile offline i dopiero po #16/#22 aktywować kontrolowany write w produkcyjnym composition root.

Założenie bezpieczeństwa

VFD Lantern nie jest safety-rated i nie zastępuje E-stop, blokad sprzętowych, LOTO, instrukcji producenta ani kwalifikowanego personelu.

Niezmienniki funkcjonalne

• Read-only default.
• Aktywna sesja tylko po Verified identification.
• Brak auto-connect, blind scan, auto-write, auto-restore, fault reset i motion.
• Produkcyjne funkcje Modbus: 3,4,6,16; brak slave 0, coils, raw PDU i FC23.
• Każdy write: process gate, Verified, trust, Armed, audit Healthy, prepare/confirm, durable Prepared, jeden write, bounded read-back, finalize.
• Brak retry write i rollback.
• Reconnect/mismatch/OutcomeUnknown/audit failure rozbraja.

Origin profilu

• Packaged — profil zgodny z manifestem wbudowanym w uruchomione binarium.
• LocalUntrusted — każdy inny profil, w tym zmieniony albo nieznany plik w /usr/share.

PackagedProfilesManifestV1

Build generuje z dokładnego zestawu zwalidowanych profili tabelę:

• build/version ID;
• profile ID;
• revision;
• profile_hash;
• write-capable flag;
• qualification_report_id dla profilu write-capable.

qualification_report_id wskazuje raport kwalifikacji danego profilu na fizycznym sprzęcie istniejący przed buildem i związany z profile hash, firmware/manual revision oraz bezpiecznym zakresem write. Nie jest tym samym co candidate HIL wykonywany później w #25; kandydat wymaga obu dowodów.

Wymagania:

1. Tabela jest wbudowana w binarium jako read-only dane.
2. Kanoniczna kopia trafia do /usr/share/vfd-lantern/manifest/profiles-v1.json oraz archiwum release.
3. Runtime nadaje Packaged wyłącznie wtedy, gdy plik profilu z systemowego katalogu ma profile ID/revision/hash zgodne z tabelą wbudowaną w binarium.
4. Dla write-capable profilu wpis bez qualification_report_id jest nieważny i nie daje Packaged write trust.
5. Kopia manifestu na dysku służy diagnostyce i package-integrity checks; nie jest root of trust i nie wpływa samodzielnie na runtime origin.
6. Brak albo mismatch kopii na dysku jest trwałym ostrzeżeniem oraz blockerem package/release tests.
7. Podmiana całego binarium przez root/właściciela instalacji pozostaje poza gwarancją i jest jawnie opisana.

Local trust

• LocalUntrusted może działać read-only po walidacji i poprawnej identyfikacji.
• Write wymaga osobnej zgody dokładnego profile_hash.
• Trust store zawiera schema, profile hash/ID/revision, czas, app version i summary pokazane operatorowi.
• Zmiana semantyki unieważnia zgodę.
• Local approval jest decyzją operatora, nie kryptograficznym root of trust.

Aktywacja write

Produkcja udostępnia arming/write dopiero gdy:

1. [PLAN 16] Zbudować dwuetapowy core prepare/confirm zapisu #16 dostarcza WriteCoordinator i capability boundary;
2. [PLAN 22] Zbudować obserwowalność, trwały AuditPort i pakiet diagnostyczny #22 dostarcza AuditPort;
3. [PLAN 23] Zamknąć profile trust, bezpieczeństwo funkcjonalne i supply chain #23 dostarcza ProfileTrustPort, embedded manifest i threat model;
4. composition root podłącza oba adaptery;
5. CI potwierdza read-only build przy braku któregokolwiek adaptera.

Bezpieczeństwo plików

• storage jest jedynym adapterem;
• profile są zwykłymi plikami, symlinki odrzucone;
• katalogi 0700, wrażliwe pliki 0600;
• create_new albo same-directory tempfile + fsync + rename;
• O_NOFOLLOW/równoważna ochrona;
• nieregularne pliki odrzucone;
• brak nazw profilu w ścieżkach;
• brak fałszywych gwarancji przeciw właścicielowi całego katalogu.

Limity wejść

Config 1 MiB; profil 4 MiB/20k parametrów/4096 faultów/256 presetów/16 KiB tekst; backup 64 MiB/20k wartości; fault/diagnostic manifest 16 MiB; limity głębokości/kolekcji; ASCII IDs; odrzucenie ESC i niedozwolonych C0/C1; checked arithmetic.

Unsafe

• domain/profile/storage/app/tui/bin: forbid unsafe;
• transport: deny unsafe z jednym modułem ioctl;
• SAFETY comments, checked layout, ADR + dwóch maintainerów dla wyjątku.

Supply chain

• Cargo.lock i --locked;
• crates.io, git/external path tylko ADR + commit pin;
• cargo-deny, cargo-audit, cargo-vet check, cargo-machete;
• CycloneDX, notices, auditable metadata;
• Dependabot;
• Actions/obrazy/narzędzia pinned;
• release checksums i attestations.

Prywatność i sieć

Brak network/update/telemetry. Seriale hashowane. Values/CSV/backup/audit/full profile tylko opt-in. Logi bez ramek/telemetrii.

Threat model

Rozróżnia przypadkowe uszkodzenie, złośliwe urządzenie, inny proces użytkownika, właściciela konta i root/właściciela instalacji. Każde zagrożenie ma inwariant, test i właściciela.

Testy

• złośliwe profile i terminal escapes;
• symlink/path traversal/irregular files;
• zmieniony profile hash i brak approval;
• systemowy plik nieobecny w embedded manifest = LocalUntrusted;
• systemowy write-capable wpis bez qualification report = brak Packaged write trust;
• kopia manifestu na dysku różna od embedded = diagnostyczny/package-integrity błąd, bez zmiany autorytatywnego porównania runtime;
• brak AuditPort/ProfileTrustPort = zero write;
• niedozwolone funkcje nieosiągalne;
• owner account może zmienić local trust store — brak fałszywego claimu;
• domyślna diagnostyka bez danych opt-in.

Kryteria akceptacji

• ProfileTrustPort używa profile_hash.
• Origin Packaged wymaga tabeli wbudowanej w binarium.
• Write-capable Packaged profile wymaga qualification_report_id istniejącego przed buildem.
• Kandydat 1.0 wymaga dodatkowo osobnego candidate HIL z [PLAN 25] Przeprowadzić hardening, self-hosted soak, HIL i bramkę wydania 1.0 #25.
• Kopia manifestu w pakiecie jest testowana pod kątem zgodności, ale nie jest runtime root of trust.
• Local approval jest poprawnie opisany.
• Produkcyjny write staje się osiągalny dopiero po AuditPort i ProfileTrustPort.
• Brak raw PDU/broadcast/motion/fault reset.
• Unsafe ograniczone do ioctl.
• Release ma SBOM/notices/checksums/attestation.
• Aplikacja działa bez root, serwera i sekretów.

Zależności

• [PLAN 01] Zablokować architekturę modularnego monolitu Rust #1
• [PLAN 02] Ustalić toolchain, wersje zależności i politykę aktualizacji #2
• [PLAN 04] Zaprojektować wersjonowany format profilu i pełną walidację #4
• [PLAN 05] Zbudować rejestr profili, dystrybucję i narzędzia autorskie #5
• [PLAN 16] Zbudować dwuetapowy core prepare/confirm zapisu #16
• [PLAN 22] Zbudować obserwowalność, trwały AuditPort i pakiet diagnostyczny #22