Academic system security · Ubuntu
FACELOCK for Ubuntu
A local face-authentication implementation for Ubuntu that integrates with PAM while retaining the normal password path and minimizing biometric data exposure.
System architecture
Secure authentication with fallback
Local web UI
Flask · enrollment · diagnostics
Ubuntu login / sudo
GDM · PAM · pam_exec
FACELOCK core
OpenCV camera → face embedding → AES-256-GCM
Match · access accepted
Failure · password fallback
PAM continues normal login.
Privacy boundary: webcam frames remain in memory; only encrypted embeddings and audit metadata are stored.
Implementation snapshot
Enrollment
3-sample averaged embedding
Protection
AES-256-GCM + bound AAD
PAM budget
6-second safe timeout
Validation
10 automated security tests
Design objective
FACELOCK explores how biometric convenience can be added to Ubuntu without making face recognition the only route into the system. The key requirement is fail-safe integration: a face match may accept authentication, while every failure must preserve the standard password path.
Authentication architecture
A local Flask control surface manages enrollment, verification, diagnostics, safe metadata, and audit review. GDM or optional sudo authentication reaches the same recognition core through PAM, pam_exec, a shell wrapper, and a narrowly scoped helper that returns controlled exit codes instead of sensitive output.
Recognition and liveness
Enrollment averages three face samples to reduce single-frame noise. Verification combines a configurable embedding-distance threshold with a short liveness sequence based on blink, head-turn, and mouth movement signals. Camera probing and backend diagnostics make capture failures visible instead of silently treating them as identity failures.
Biometric data protection
The implementation minimizes the material that would be exposed by a database leak.
- Webcam frames are processed in memory and never persisted
- Only face embeddings are stored, encrypted with AES-256-GCM
- Authenticated additional data binds ciphertext to the username and per-record salt
- The production database and master key live under separate protected paths
- Authentication and administration events form a SHA-256-linked audit chain with tamper verification
Fail-safe deployment and testing
Installation is staged through configuration checks and pamtester before GDM is changed. A six-second PAM budget, explicit enablement flags, backups, diagnostics, uninstall support, and password fallback reduce lockout risk. Automated tests cover encryption round trips and identity binding, user CRUD, audit-chain tampering, PAM success and fallback, safe user listing, and web routes.
Known limitations
This is an academic system, not certified biometric authentication. Liveness detection is basic, TPM-backed key sealing is not enabled by default, and accuracy remains sensitive to lighting, camera stability, and enrollment quality.