shekh-2810 / AstraLock AstraLock is a lightweight face-authentication system designed for Linux. It replaces legacy camera pipelines with modern deep-learning models, optimized preprocessing, and a clean, modular architecture. The goal is simple: reliable face-based login on Linux without the sluggishness, low-light failures, or angle sensitivity seen in older tools. AstraLock AstraLock is a Linux biometric authentication system that enables face-based login through PAM and systemd, designed to be offline, auditable, and hackable, offering a native Linux alternative to projects like Howdy and closed platforms such as Windows Hello without cloud dependencies.

It runs a local daemon that performs facial verification and integrates directly with system authentication flows such as sudo, login, display managers, and polkit. What AstraLock Is A system daemon that performs face verification A PAM module (pam_facelock.so) for system authentication A CLI tool for enrollment, verification, and testing A local-only LBPH model (no cloud, no network) No external services.No telemetry.No vendor lock-in. Features 🔐PAM authentication (login, sudo, polkit, display managers)🧠Offline facial recognition (LBPH, OpenCV) ⚙️systemd-managed daemon lifecycle📷 Webcam support via OpenCV🧪Built-in testing via pamtester Simple CLI for users and admins Architecture… View on GitHub

shekh-2810 / AstraLock

AstraLock is a lightweight face-authentication system designed for Linux. It replaces legacy camera pipelines with modern deep-learning models, optimized preprocessing, and a clean, modular architecture. The goal is simple: reliable face-based login on Linux without the sluggishness, low-light failures, or angle sensitivity seen in older tools.

AstraLock

What AstraLock Is

Features

Architecture

The Problem with Existing Approaches

Design Goals

High-Level Architecture

Why this design?

Recognition Pipeline

Key Challenges

1. PAM Behavior is Subtle

2. Display Managers Are Inconsistent

3. Camera Reliability

4. Avoiding Lockouts

Current Capabilities

Security Considerations

What I Learned

Looking for Feedback

Project Linux still lacks a reliable, native biometric authentication system. While platforms like Windows and macOS have tightly integrated face authentication, Linux users typically rely on passwords — or experimental tools that often break under real-world conditions. So I built AstraLock. AstraLock is a Linux biometric authentication system that enables face-based login through PAM and systemd, designed to be offline, auditable, and hackable, offering a native Linux alternative to projects like Howdy and closed platforms such as Windows Hello without cloud dependencies. It runs a local daemon that performs facial verification and integrates directly with system authentication flows such as sudo, login, display managers, and polkit. A system daemon that performs face verification A PAM module (pam_facelock.so) for system authentication A CLI tool for enrollment, verification, and testing A local-only LBPH model (no cloud, no network) No external services.No telemetry.

No vendor lock-in. Most existing solutions (like Howdy) work — until they don’t. The biggest issue wasn’t the ML part — it was system integration. Before writing code, I defined strict constraints: Instead of embedding everything inside PAM, I separated concerns: PAM modules should stay minimal and predictable. Heavy operations like: are handled by a separate daemon. This avoids blocking PAM and improves reliability. The pipeline uses modern ONNX-based models: Everything runs locally. No external APIs. No network calls. The biggest issue was handling: Small changes in PAM configuration can completely change outcomes. GDM, SDDM, and others: This required testing across environments. Accessing /dev/video* sounds simple — but: Biometric authentication is probabilistic. This is not meant to replace passwords entirely. The system is designed for: convenience + controlled risk, not absolute security I’m particularly interested in input on: AstraLock is open source and still evolving. If you’ve worked with PAM, Linux auth, or system-level tooling, I’d appreciate your perspective. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to ? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse

Code Block

Copy

display managers display managers Application (sudo / login / GUI) ↓ PAM ↓ pam_facelock.so ↓ facelockd (systemd service) ↓ UNIX socket IPC ↓ Face recognition pipeline Application (sudo / login / GUI) ↓ PAM ↓ pam_facelock.so ↓ facelockd (systemd service) ↓ UNIX socket IPC ↓ Face recognition pipeline Application (sudo / login / GUI) ↓ PAM ↓ pam_facelock.so ↓ facelockd (systemd service) ↓ UNIX socket IPC ↓ Face recognition pipeline auth sufficient /dev/video* - fully offline - predictable under PAM - extensible and debuggable - A system daemon that performs face verification - A PAM module (pam_facelock.so) for system authentication - A CLI tool for enrollment, verification, and testing - A local-only LBPH model (no cloud, no network) - 🔐PAM authentication (login, sudo, polkit, display managers) - 🧠Offline facial recognition (LBPH, OpenCV) - ⚙️systemd-managed daemon lifecycle - 📷 Webcam support via OpenCV - 🧪Built-in testing via pamtester - Simple CLI for users and admins - PAM inconsistencies across sudo, login, and display managers - unreliable camera handling - fragile integration with system components - limited control over the authentication pipeline - No cloud dependencies - No telemetry - Deterministic PAM behavior - Clean separation between authentication logic and ML - Works across CLI and GUI authentication flows - camera access - model inference - image processing - Face detection (RetinaFace) - Face alignment (landmark-based) - Embedding generation (ArcFace, 512-dim) - Cosine similarity for matching - auth sufficient vs required - fallback to password authentication - inconsistent behavior across services - handle authentication differently - sometimes retry unexpectedly - may break assumptions about flow - permissions vary - devices differ - latency can affect authentication timing - password fallback is always preserved - PAM is configured as sufficient, not exclusive - Works with sudo, login, and GUI prompts (polkit) - Fully offline inference - Local model storage per user - systemd-managed daemon - CLI for enrollment and verification - biometric matching is probabilistic - spoofing is a real concern - fallback authentication is required - System integration is harder than ML - PAM is powerful but unforgiving - Reliability matters more than accuracy - Simplicity in design reduces failure cases - PAM edge cases in real-world deployments - failure modes I might be missing - biometric authentication tradeoffs on Linux - ways to improve reliability without sacrificing usability