irlume is biometric authentication software: a bug here can mean unauthorized login.
Pre-1.0, not yet suitable for production. There is no long-term-support
branch; security fixes land on main and ship in the next release.
| Version | Supported |
|---|---|
main / latest release |
✅ |
| older pre-1.0 tags | ❌ |
| Tier | Components | Why |
|---|---|---|
| Critical | irlume-pam (auth path), irlume-daemon (privileged) |
A flaw grants login or root |
| High | irlume-vision (inference + match), irlume-liveness (PAD), bundled model integrity |
Bypass of recognition or anti-spoofing |
| Medium | irlume-camera (device/IR control), irlume-core (TPM/storage), packaging/systemd units |
Trust boundary + secret handling |
| Low | irlume-cli |
Unprivileged client |
Full detail in docs/THREAT_MODEL.md. Primary concerns:
- Authentication bypass:
PAM_SUCCESSwithout a genuine live match; FFI unsoundness in the PAM module. The module never grants on error: any error, timeout, or unavailable daemon returnsPAM_IGNORE(a neutral result, neverSUCCESS), so the stack falls through to the password. - Presentation/injection attacks: printed/screen/3D-mask spoofs and the Windows Hello-class USB IR-frame injection (CVE-2021-34466). Defended by the algorithmic IR liveness gate, device-trust binding, and cross-spectrum RGB↔IR consistency.
- Biometric data leakage: templates/embeddings are sensitive. They are zeroized where the exposure is real (keys, secrets, IPC buffers); frames/embeddings are transient daemon memory, never logged, and the unlock secret is TPM-sealed (not the template).
- Side channels: the match comparison is value-independent in timing so a similarity score cannot be inferred from response time.
- Model integrity: model weights are pinned by SHA-256 (committed in
models/SHA256SUMS;scripts/fetch-models.shverifies each release-hosted weight against its hash before use) and ship inside the distro packages, whose own integrity checking covers them; only the permissive, audited BOM is shipped. At startup the daemon re-hashes each configured model against the release manifest (models/SHA256SUMS, embedded at build time) and logs a loud warning on any mismatch;IRLUME_MODELS_STRICT=1turns both a mismatch and an unreadable/deleted model into a startup refusal. Warn-first is the default so a recoverable mis-packaging (or a deliberately overridden model path via the unit'sIRLUME_*_MODELvariables) degrades to a loud warning instead of bricking face login; strict is the hardened choice.
Do not open a public issue for security bugs. Instead:
- Use GitHub Private Vulnerability Reporting on this repository, or
- Email archledger236@gmail.com.
Please include affected version/commit, a description, and a reproduction if possible.
- Acknowledgement: within 48 hours.
- Assessment: within 7 days.
- Fix target: 30 days for Critical/High severity.
- Disclosure: coordinated, with a 90-day window. Reporters are credited in the release notes (opt-in).
- CVE IDs: requested through GitHub Security Advisories (GitHub is a CVE Numbering Authority for repository vulnerabilities), so a confirmed vulnerability gets a CVE and a published advisory alongside the fix release, and the fix is named in that release's notes.
In scope: anything that bypasses authentication, leaks biometric data, escalates privilege, or defeats the liveness gate. Out of scope: attacks requiring a pre-compromised root account, physical destruction, or social engineering of the enrolled user.