Архитектура Tessera

This content is not available in your language yet.

Этот документ — единая ссылочная архитектура версии 0.1.1. После прочтения инженер должен корректно отвечать на вопросы:

что происходит при вызове pam_sm_authenticate?
что лежит в /run/tessera/?
что делает monitord при udev REMOVE-событии?
как сериализуется IPC и какие сообщения проходят между PAM-модулем и monitord?

1. Цели и не-цели

1.1 Что Tessera делает

Аутентифицирует локального UNIX-пользователя по X.509-сертификату на USB-носителе или PKCS#11-токене.
Привязывает пользователя к машине (host-binding) через X.509 v3 расширения pam_cert_host_binding и pam_cert_user_binding, встроенные в сам leaf-сертификат.
Мониторит состояние USB-носителя в течение сессии и реагирует на его извлечение (lock / logout / hook / shutdown).
Корректно обрабатывает suspend/resume.
Делегирует ГОСТ-криптографию сертифицированному gost-engine.

1.2 Что Tessera НЕ делает

Не реализует свою криптографию (всё через OpenSSL и gost-engine).
Не управляет жизненным циклом CA (выпуск/отзыв сертификатов — задача внешнего УЦ).
Не управляет PIN-кодами токенов (это задача администратора и пользователя).
Не защищает от компрометации root-аккаунта или ядра ОС (вне TOE).
Не выполняет сетевых запросов вообще: revocation — только локальный CRL; OCSP не реализован (mode = "ocsp" отвергается валидацией конфига).

Полное описание границ TOE — в docs/threat-model.md.

2. Компоненты

tessera — это workspace из четырёх крейтов и одна ОС-интеграция (systemd, udev, logind).

2.1 `tessera_core` (rlib)

Синхронное ядро. Содержит:

Загрузку и валидацию конфигурации (config::raw::RawConfig → config::validated::ValidatedConfig).
Парсинг и проверку X.509 (x509/).
Цепочки доверия и проверку CRL (trust/, crl/).
Challenge-response (challenge/).
ГОСТ-делегацию через gost-engine (gost/).
PKCS#12 и PKCS#11 (pkcs12/, token/).
USB-mount и MountGuard RAII (usb/, mount/).
Хуки (hooks/).
Host identity chain (host_identity/).
Cert-scope verification — парсинг расширений pam_cert_host_binding / pam_cert_user_binding и сверка их записей с host_id_hash и pam_user (x509/, verify_cert_scope).
IPC client side (ipc/).

Без tokio, без асинхронности. Все операции блокирующие — это оправдано: PAM-модуль вызывается из синхронного контекста libpam.

2.2 `tessera_proto` (rlib)

Wire-протокол IPC между PAM-модулем и демоном. Содержит:

ClientMessage и ServerMessage — варианты сообщений (crates/tessera_proto/src/client.rs, .../server.rs).
WireError и encode/decode-функции (wire.rs).
framing::FramingError — кадрирование NDJSON.
SessionTarget — кодирует tty/display/logind-id для конкретной сессии.
PROTOCOL_VERSION — текущее значение 2.

#![forbid(unsafe_code)] — крейт чисто-safe.

2.3 `pam_tessera` (cdylib `libpam_tessera.so`)

PAM service module. Содержит:

PAM entry points: pam_sm_authenticate, pam_sm_setcred, pam_sm_acct_mgmt, pam_sm_open_session, pam_sm_close_session (см. crates/pam_tessera/src/entry.rs).
Panic guard (panic_guard.rs) — каждая C-граница защищена catch_unwind, panic → PAM_AUTHINFO_UNAVAIL.
DI wiring (di.rs) — собирает зависимости ядра из конфига.
Flow orchestrator (flow.rs) — основной авторизационный пайплайн.
PAM conversation helpers (pam_conv.rs).
Persistent data между pam_sm_* вызовами (pam_data.rs).

Билдится в /lib/security/pam_tessera.so (см. debian/rules).

2.4 `tessera_cli` (бинарь `tessera`)

Долгоживущий демон, владеющий:

Сокетом IPC (/run/tessera/monitord.sock).
udev-мониторингом USB-устройств (udev_monitor.rs).
D-Bus подключением к systemd-logind (logind.rs).
Реестром активных сессий (registry.rs, state.rs).

Основан на tokio multi-thread (см. main.rs). Использует sd_notify для интеграции с systemd Type=notify. Билдится в /usr/bin/tessera и поставляется юнитом tessera.service.

2.5 Внешние зависимости

Компонент	Источник	Доверие
`libpam0g`	системный, Astra/Debian repo	да
`libssl3`	системный, Astra/Debian repo	да
`gost-engine`	Astra SE 1.7+ (СКЗИ ФСБ)	да (в составе сертифицированной ОС)
`librtpkcs11ecp.so`	Рутокен, поставляется отдельно	да (СКЗИ ФСБ)
`libjcPKCS11.so`	JaCarta, поставляется отдельно	да (СКЗИ ФСБ)
`libudev1`	системный, Astra/Debian repo	да
`libdbus-1-3`	системный, Astra/Debian repo	да
`libsystemd0`	системный, Astra/Debian repo	да

ГОСТ и PKCS#11. Подпись ГОСТ-алгоритмами работает только на PKCS#12-пути — через gost-engine в OpenSSL. На PKCS#11-пути (librtpkcs11ecp.so, libjcPKCS11.so) ГОСТ-механизмы не поддержаны (crate cryptoki не покрывает GOST mechanisms); Рутокен/JaCarta на PKCS#11 применимы для RSA/ECDSA-сертификатов. Поддержка GOST-на-PKCS#11 — proposal openspec/changes/gost-pkcs11.

3. Crate dependency diagram

flowchart TD
    libpam[libpam.so] --> cdylib[libpam_tessera.so]
    cdylib --> core[tessera_core]
    cdylib --> proto[tessera_proto]
    monitord[tessera] --> proto
    monitord --> core
    cdylib -. "AF_UNIX SOCK_STREAM NDJSON" .-> monitord
    core --> openssl[libssl3 + gost-engine]
    core --> pkcs11[PKCS#11 module]
    monitord --> udev[libudev]
    monitord --> dbus[libdbus / logind]

4. Жизненный цикл PAM-вызовов

PAM-стек делает несколько вызовов в порядке auth → account → session. tessera обрабатывает их все, но реальная работа — в pam_sm_authenticate. Остальные читают сохранённый AuthContext из PAM data.

4.1 `pam_sm_authenticate`

Распаковать аргументы модуля (config=...).
Загрузить и валидировать config.toml (через tessera_core::config::load_validated_config). При ошибке — PAM_AUTHINFO_UNAVAIL.
Запустить self_check (engine, paths, hooks placeholders). При ошибке — PAM_AUTHINFO_UNAVAIL.
Прочитать PAM_USER, PAM_SERVICE, PAM_TTY из libpam.
Через di::wire собрать DI-граф (mount, trust, token).
Резолвить host_id через цепочку источников из конфига и вычислить host_id_hash = sha256(host_id).
Запустить flow::authenticate(ctx):
- смонтировать USB или открыть PKCS#11-сессию;
- найти сертификат, проверить цепь и revocation;
- challenge-response с приватным ключом;
- извлечь расширения pam_cert_host_binding и pam_cert_user_binding из leaf-сертификата и сверить их с host_id_hash и pam_user через verify_cert_scope. Когда pam_cert_user_binding присутствует, это единственный источник авторизации для PAM-пользователя; список [[user_mapping]] из config.toml в этом случае не читается. Если pam_cert_user_binding отсутствует — модуль откатывается на legacy-сравнение через [[user_mapping]]. Поведение зафиксировано тестом в crates/pam_tessera/tests/negative_auth.rs на фикстуре leaf_no_user_binding (см. также unit-тест в crates/pam_tessera/src/flow.rs).
При успехе — построить AuthContext и сохранить через pam_set_data.
Отправить Hello + SessionOpen в monitord (получить Ack).
Вернуть PAM_SUCCESS. Любая ошибка маппится в PAM_AUTHINFO_UNAVAIL / PAM_PERM_DENIED / PAM_MAXTRIES / PAM_AUTH_ERR / PAM_SYSTEM_ERR по семантике flow::FlowError::pam_code (таблица — в §13).

4.2 `pam_sm_setcred`

Не делает ничего сверх PAM_SUCCESS. Сертификаты не размещаются в keyring пользователя.

4.3 `pam_sm_acct_mgmt`

Читает AuthContext, проверяет, что:

notAfter сертификата ещё не истёк (с допуском clock_skew_seconds; значение берётся из конфига в момент pam_sm_authenticate и сохраняется в AuthContext).

При несоответствии возвращает PAM_ACCT_EXPIRED.

4.4 `pam_sm_open_session`

Читает AuthContext. Отправляет в monitord SessionOpen с полным payload’ом (см. client.rs::SessionOpenPayload):

session_id (UUID);
pam_user, pam_service;
target (Tty / Display / LogindSession);
usb_serial — серийник носителя, авторизовавшего сессию;
host_id_hash — hex SHA-256 от host_id;
opened_at — wall-clock unix-время;
cert_cn, cert_serial.

Monitord добавляет сессию в реестр и начинает мониторинг USB.

4.5 `pam_sm_close_session`

Отправляет SessionClose { session_id, closed_at }. Monitord удаляет сессию из реестра и не триггерит on_usb_removed — пользователь явно завершил сессию.

5. Файловая раскладка во время работы

flowchart LR
    etc["/etc/tessera/"] --> cfg[config.toml]
    etc --> ca["ca/bundle.pem"]
    etc --> crl["crl/*.pem"]
    run["/run/tessera/"] --> sock[monitord.sock]
    run --> sessions["sessions/sid/"]
    run --> state[sessions.json]
    run --> lock[daemon.lock]
    var["/var/lib/tessera/"] --> wp["wallpaper.orig.jpg"]

Путь	Кто пишет	Кто читает	Права
`/etc/tessera/config.toml`	администратор	cdylib + monitord	`0640 root:root`
`/etc/tessera/ca/bundle.pem`	администратор	cdylib + monitord	`0640 root:root`
`/run/tessera/monitord.sock`	monitord	cdylib	`0660 root:tessera`
`/run/tessera/sessions/<sid>/`	cdylib	удаляет MountGuard на drop	`0700 root:root`
`/run/tessera/sessions.json`	monitord	monitord (между перезапусками демона в пределах boot; tmpfs, volatile)	`0600 tessera:tessera`
`/run/tessera/daemon.lock`	monitord (flock-singleton; рядом с `sessions.json`, fallback `/var/lib/tessera/`)	monitord	—

/run/tessera/ и /var/lib/tessera/ создаются systemd через директивы RuntimeDirectory и StateDirectory юнита (см. tessera.service и dist/tmpfiles/tessera.conf).

6. Sequence diagram — `pam_sm_authenticate` happy path с PKCS#11

sequenceDiagram
    participant U as User
    participant L as libpam
    participant P as cdylib
    participant C as core
    participant T as PKCS#11 module
    participant M as monitord

    U->>L: попытка входа
    L->>P: pam_sm_authenticate
    P->>C: load_validated_config
    P->>C: self_check
    P->>C: resolve_host_identity
    C->>T: C_OpenSession
    P->>U: запрос PIN
    U->>P: PIN
    P->>T: C_Login
    T-->>P: cert + privkey handles
    C->>C: build_chain + verify_chain
    C->>C: revocation check
    P->>U: запрос challenge
    P->>T: C_Sign(challenge)
    T-->>P: signature
    C->>C: verify(signature, pubkey, challenge)
    C->>C: parse_cert_extensions + verify_cert_scope
    P->>M: Hello(protocol_version=2)
    M-->>P: HelloAck
    P->>L: PAM_SUCCESS

7. Sequence diagram — `pam_sm_open_session` + IPC `SessionOpen`

sequenceDiagram
    participant L as libpam
    participant P as cdylib
    participant M as monitord

    L->>P: pam_sm_open_session
    P->>P: read AuthContext from pam_data
    P->>M: SessionOpen payload
    M->>M: registry.insert(session_id)
    M->>M: start udev watch for usb_serial
    M-->>P: Ack
    P->>L: PAM_SUCCESS

8. Sequence diagram — USB removal → grace → lock

sequenceDiagram
    participant K as kernel/udev
    participant M as monitord
    participant L as logind
    participant U as User session

    K->>M: udev REMOVE event
    M->>M: lookup session by serial
    M->>M: start grace timer
    alt USB не вернулся за grace
        M->>L: LockSession(id)
        L->>U: lock screen
    else USB вернулся
        K->>M: udev ADD event
        M->>M: cancel grace timer
        M->>M: log removal cancelled
    end

Поведение on_usb_removed:

"lock" — LockSession (по умолчанию).
"logout" — TerminateSession.
"hook" — выполняется хук usb_removed.
"shutdown" — PowerOff через D-Bus к logind.

9. Sequence diagram — suspend / resume

sequenceDiagram
    participant L as logind
    participant M as monitord

    L->>M: PrepareForSleep(true)
    M->>M: snapshot active sessions
    Note right of M: udev REMOVE-события<br/>в течение suspend<br/>будут отмечены transient
    L->>M: PrepareForSleep(false)
    M->>M: arm suspend_grace timer
    Note right of M: пока таймер активен,<br/>любые udev REMOVE<br/>с reinsertion в grace<br/>игнорируются

При monitor_fail_mode = "strict" cdylib ожидает Ack от monitord по таймауту; при "permissive" — переживает кратковременную недоступность.

10. IPC wire protocol

10.1 Транспорт

AF_UNIX SOCK_STREAM.
Путь сокета: /run/tessera/monitord.sock.
Права: 0660 root:tessera (см. tmpfiles + systemd RuntimeDirectory).
Аутентификация peer’а: SO_PEERCRED — monitord проверяет, что uid == 0. Любой иной peer закрывается.
Реализация: crates/tessera_cli/src/peercred.rs.

10.2 Кадрирование

Newline-delimited JSON (NDJSON):

каждый кадр — единственная строка UTF-8 JSON;
терминатор — единственный байт \n;
максимальный размер кадра — MAX_FRAME_BYTES = 64 KiB (см. crates/tessera_proto/src/wire.rs).

Обоснование выбора NDJSON:

стандартные tools (jq, journalctl-форматер) умеют обрабатывать его без специальной поддержки;
кадрирование тривиально — \n-deliмитер;
расходы на парсинг JSON оправданы низкой частотой сообщений (≤ 10 в секунду в типовом дне).

10.3 Версионирование

PROTOCOL_VERSION: u32 = 2 (см. crates/tessera_proto/src/version.rs). Версия 2 добавила GetActiveSessionByUid / ActiveSession, опциональные поля SessionOpen (engineer_ski, engineer_cert_sha256, uid) и код ошибки NO_ACTIVE_SESSION (1200); кадры v1-клиента без новых полей десериализуются.
Первый кадр на любом соединении — Hello { protocol_version }.
Если protocol_version не равен серверному, monitord отвечает Error { code: 1000 (PROTOCOL_MISMATCH) } и закрывает соединение.
Семантика версий: MAJOR-mismatch → разрыв; MINOR (если появятся) — best-effort backward compatibility.

10.4 Сообщения

Client → Server (`ClientMessage`)

Из crates/tessera_proto/src/client.rs:

{"type": "hello", "protocol_version": 2, "agent": "libpam_tessera/0.1.1"}

{"type": "session_open", "session_id": "1c5e8a90-3b6f-4a1d-9c2e-77f0b1c2d3e4", "pam_user": "alice", "pam_service": "sudo", "target": {"kind": "logind_session", "id": "12"}, "usb_serial": "RUTOKEN-001", "host_id_hash": "ee0bd4f3a3c8e21d4a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f", "opened_at": 1735689600, "cert_cn": "Alice", "cert_serial": "01a2b3c4d5e6f70809"}

{"type": "session_close", "session_id": "1c5e8a90-3b6f-4a1d-9c2e-77f0b1c2d3e4", "closed_at": 1735689700}

{"type": "ping"}

Server → Client (`ServerMessage`)

Из crates/tessera_proto/src/server.rs:

{"type": "hello_ack", "server_version": "0.1.1", "protocol_version": 2}

{"type": "ack"}

{"type": "pong"}

{"type": "error", "code": 1000, "message": "protocol version mismatch"}

10.5 Таблица «инициатор → получатель → ответ → таймаут»

Initiator	Сообщение	Получатель	Ожидаемый ответ	Таймаут	Действие при timeout
client	`Hello`	server	`HelloAck` или `Error`	2 сек	разрыв соединения
client	`SessionOpen`	server	`Ack` или `Error`	2 сек	согласно `monitor_fail_mode`
client	`SessionClose`	server	`Ack`	1 сек	log + продолжить
client	`Ping`	server	`Pong`	1 сек	log + продолжить

10.6 Коды ошибок

Из crates/tessera_proto/src/server.rs:

Код	Имя	Семантика	Действие cdylib
1000	PROTOCOL_MISMATCH	Версии протокола не совпали.	fail-closed
1001	DEVICE_GONE	USB-устройство по `usb_serial` отсутствует.	fail-closed
1003	UNAUTHORIZED	Peer не uid=0 (по `SO_PEERCRED`).	разрыв
1100	BAD_REQUEST	Невалидный кадр (нарушение схемы).	разрыв + log
1101	PROTOCOL_VIOLATION	Нарушение wire-протокола: oversize-кадр, idle-таймаут и т.п. Сервер закрывает соединение после отправки.	разрыв + log
1200	NO_ACTIVE_SESSION	Нет активной сессии для запрошенного uid (ответ v2-демона на `GetActiveSessionByUid`).	штатный «не найдено»
1500	INTERNAL	Внутренняя ошибка демона.	по `monitor_fail_mode`

DEVICE_GONE и UNAUTHORIZED фатальны всегда — они меняют вердикт аутентификации и пробрасываются даже в permissive (ipc/failmode.rs). Остальные ошибки — по политике monitor_fail_mode на конкретном call-site; на auth-пути сбой уведомления monitord не отменяет уже состоявшийся успех аутентификации (см. §13).

10.7 JSON-схема `SessionOpenPayload`

{
  "title": "SessionOpenPayload",
  "type": "object",
  "properties": {
    "session_id":   {"type": "string", "format": "uuid"},
    "pam_user":     {"type": "string"},
    "pam_service":  {"type": "string"},
    "target":       {"type": "object"},
    "usb_serial":   {"type": ["string", "null"]},
    "host_id_hash": {"type": "string", "pattern": "^[0-9a-f]{64}$"},
    "opened_at":    {"type": "integer"},
    "cert_cn":      {"type": "string"},
    "cert_serial":  {"type": "string", "pattern": "^[0-9a-f]+$"}
  },
  "required": ["session_id", "pam_user", "pam_service", "target", "host_id_hash", "opened_at", "cert_cn", "cert_serial"]
}

11. Threading и concurrency model

11.1 cdylib

Полностью синхронный, без tokio.
Соединение с monitord — единственное per pam_sm_* вызов; закрывается после ответа.
Без shared mutable state: каждый PAM-вызов имеет собственный flow::Context.

11.2 monitord

tokio multi-thread runtime (количество worker threads — по умолчанию системный default tokio).
На каждое входящее соединение — отдельная задача (server.rs::handle_connection).
Реестр сессий — Mutex<RegistryStore> (см. registry.rs).
udev и logind — свои dedicated long-running tasks.
Запись /run/tessera/sessions.json — atomic-rename через tempfile (без flock; от двойного запуска демона защищает отдельный singleton-замок daemon.lock). Файл лежит на tmpfs (RuntimeDirectory=tessera), intentionally volatile: реестр нужен только между перезапусками демона в пределах одного boot — все процессы, держащие эти сессии (sshd/login/ sudo), всё равно умирают на reboot.

11.3 Совместный доступ к `/run/tessera/sessions/`

cdylib создаёт каталог <sid> через MountGuard::new (RAII).
Удаляет каталог в Drop (или в pam_sm_close_session).
monitord не пишет в этот каталог напрямую — только читает при диагностике.

12. Host identity chain

host_id вычисляется в момент pam_sm_authenticate через цепочку источников из секции [host_identity]. Реализация — crates/tessera_core/src/host_identity/chain.rs.

Источники в порядке предпочтения:

machine_id — /etc/machine-id (стабилен между перезагрузками, меняется при переустановке).
dmi_board_serial — /sys/class/dmi/id/board_serial (стабилен на уровне железа, меняется при замене материнской платы).
dmi_system_uuid / dmi_system_serial — DMI-идентификаторы системы (стабильность зависит от вендора/гипервизора).
hostname — /etc/hostname (нестабилен, легко подменяется; OK для тестов).
custom_command — администраторский скрипт.
override — фиксированное значение из конфига (bootstrap/тесты).

Цепочка обходится в указанном sources порядке. Первый непустой результат — победитель. Если все источники пустые:

fallback = "deny" → PAM_AUTH_ERR (production по умолчанию);
fallback = "warn" → PAM_SUCCESS с warning-логом (тестовое окружение);
fallback = "allow" → PAM_SUCCESS молча (опасно, не использовать).

13. Fail-closed правила

#	Условие	Возврат
1	panic в любом `pam_sm_*`	`PAM_AUTHINFO_UNAVAIL` (9)
2	загрузка `config.toml` упала	`PAM_AUTHINFO_UNAVAIL` (9)
3	`self_check` упал (engine, paths, hooks)	`PAM_AUTHINFO_UNAVAIL` (9)
4	USB/mount/discovery не дали носителя, PKCS#11-модуль не загрузился	`PAM_AUTHINFO_UNAVAIL` (9)
5	сертификат не проходит chain verification	`PAM_PERM_DENIED` (6)
6	revocation check провалился (`mode = "crl"`: серийник в CRL, CRL отсутствует или несвеж)	`PAM_PERM_DENIED` (6)
7	challenge-response не сошёлся	`PAM_PERM_DENIED` (6)
8	legacy `[[user_mapping]]` не дал совпадения	`PAM_PERM_DENIED` (6)
9	исчерпан лимит попыток PIN (`MaxTries`, `PinLocked`)	`PAM_MAXTRIES` (8)
10	расширение `pam_cert_host_binding` отсутствует или невалидно	`PAM_AUTH_ERR` (7)
11	host_id_hash не входит в записи `pam_cert_host_binding`	`PAM_AUTH_ERR` (7)
12	расширение `pam_cert_user_binding` отсутствует или невалидно	`PAM_AUTH_ERR` (7)
13	`pam_user` не входит в записи `pam_cert_user_binding`	`PAM_AUTH_ERR` (7)
14	единичная ошибка PIN, ошибка PAM conversation, отказ хука	`PAM_AUTH_ERR` (7)
15	нарушение внутренних инвариантов (`Internal`)	`PAM_SYSTEM_ERR` (4)
16	`Error` из monitord с `code = DEVICE_GONE` / `UNAUTHORIZED`	пробрасывается всегда, даже в `permissive`

Полная таблица соответствия FlowError → PAM-код — doc-comment FlowError::pam_code в crates/pam_tessera/src/flow.rs.

Принципы:

panic’и и инфраструктурные ошибки → PAM_AUTHINFO_UNAVAIL (сообщает PAM-стеку: «следующий модуль может попробовать»).
Отказы криптографической проверки (цепь, revocation, challenge-response, mapping) → PAM_PERM_DENIED; отказы cert-scope (pam_cert_host_binding / pam_cert_user_binding) и прочие auth-ошибки → PAM_AUTH_ERR; исчерпанный PIN-бюджет → PAM_MAXTRIES.
Недоступность monitord не делает auth fail-closed даже при monitor_fail_mode = "strict": фатальны (меняют вердикт) только DEVICE_GONE и UNAUTHORIZED (crates/tessera_core/src/ipc/failmode.rs); транспортные ошибки IPC на auth-пути логируются как non-fatal — уведомление monitord идёт после уже состоявшегося успеха аутентификации. strict / permissive управляют лишь тем, пробрасывает ли обёртка FailModeWrapper нефатальные ошибки IPC вызывающему коду.

14. Журналирование `tracing` → syslog / journald

tracing-подписчик cdylib pam_tessera.so строится в момент первого вызова pam_sm_* и шлёт записи в syslog через LOG_AUTH facility с ident tessera. На системах с journald эти строки видны через journalctl -t tessera и попадают в /var/log/auth.log (на обычном syslog-стеке) с префиксом tessera[<pid>]:. Это поведение появилось в 0.1.1 (fix(pam): wire syslog backend for tracing subscriber) — в 0.1.0 cdylib писал в stderr, который libpam отбрасывал, и production-диагностика была фактически невозможна.

tessera использует tracing-journald и пишет в journald через нативный Type=notify-канал. На SysV-init хостах без journald записи tracing уходят в stderr демона; куда они попадут дальше — определяется тем, как init-скрипт перенаправляет stderr (в стандартной поставке start-stop-daemon отдаёт stderr системному syslog’у через logger).

Полная семантика того, что и на каком уровне логируется, — в docs/operations.md §6.

15. Дальнейшее чтение

docs/threat-model.md — какие угрозы покрывает каждый из этих fail-closed правил.
docs/configuration.md — какие поля влияют на поведение, описанное здесь.
docs/operations.md — как читать журнал и диагностировать аномалии.