Super STT implements a comprehensive defense-in-depth security model to protect against unauthorized access while maintaining usability. The system uses multiple security layers including Unix domain sockets with group-based access control, process authentication for keyboard access, and input validation throughout.

Based on comprehensive security reviews completed in August 2025, Super STT demonstrates excellent security posture with:

• ✅ Process Authentication: Robust authentication for keyboard injection operations
• ✅ Input Validation: Comprehensive framework with DoS protection and attack detection
• ✅ Memory Safety: Excellent use of Rust's safety guarantees
• ✅ Network Security: Localhost-only UDP binding prevents remote attacks
• ✅ Resource Management: Connection limits and rate limiting prevent abuse
• ✅ Path Security: Comprehensive validation prevents directory traversal attacks

Security Assessment: Production-ready with excellent security controls implemented.

• Permissions: 0660 (read/write for owner and group)
• Group: stt
• Access: Only the daemon owner and members of the stt group can connect

• Permissions: 0666 (world accessible)
• Enable: Automatically enabled in debug builds (cargo build)
• Warning: Only use for local development, never in production

The installation process creates an stt system group. Users who need to access the Super STT daemon must be members of this group.

# Automatic during installation
just install-daemon

# Or manual setup
sudo groupadd stt
sudo usermod -a -G stt $USER
# Log out and back in for changes to take effect

# Check your groups
groups

# Verify socket permissions
ls -la $XDG_RUNTIME_DIR/stt/super-stt.sock
# Should show: srw-rw---- ... user stt ... super-stt.sock

• Process authentication: Write mode requires verification that the client is the legitimate stt binary
• Unix socket credentials: Uses peer credential verification to authenticate processes
• Debug/release separation: Authentication automatically disabled in debug builds for development
• Limited scope: Only types actual transcription results

• UDP localhost-only: Audio streaming bound to 127.0.0.1
• No remote access: Network connections impossible
• Read-only broadcast: Only sends visualization data

• Unix peer credentials: Verifies connecting process PID, UID, and executable path
• Binary verification: Ensures only the legitimate stt binary can trigger write mode
• Compile-time security: Uses cfg!(debug_assertions) to automatically disable in debug builds
• Fallback checks: Validates process name if path verification fails

• Comprehensive validation: All external inputs validated with strict limits
• Audio data protection: Maximum 30 minutes of audio at 16kHz to prevent memory exhaustion
• Sample rate validation: Must be between 8kHz and 96kHz
• JSON protection: Size (1MB) and nesting depth (10 levels) limits prevent JSON bomb attacks
• Suspicious pattern detection: Detects potential padding attacks in audio data
• Control character filtering: Prevents injection of dangerous characters

• Connection limits: Maximum concurrent connections enforced (20 in production, 50 in development)
• Rate limiting: Per-client request limits with sliding window tracking
  • Production: 60 requests/minute, 1800 requests/hour
  • Development: 300 requests/minute, 7200 requests/hour
• Connection timeouts: Automatic cleanup of inactive connections (3 minutes production, 10 minutes development)
• Memory protection: Resource limits prevent memory exhaustion attacks

• User service: Runs under user account, not root
• Group separation: Multi-user systems can control access via group membership
• Socket permissions: Enforced at filesystem level
• Process authentication: SO_PEERCRED verification for privileged operations

The default configuration is secure for personal desktop use:

just install-daemon

1. Ensure only trusted users are in the stt group
2. Consider using separate user accounts for the daemon
3. Monitor group membership: getent group stt

Debug builds automatically use relaxed security for development convenience:

# Debug build - automatically skips process authentication
cargo run --bin super-stt

# Release build - enforces full security model
cargo run --release --bin super-stt

• ✅ Unauthorized local users accessing the daemon
• ✅ Remote network attacks (localhost-only UDP binding)
• ✅ Unauthorized keyboard injection (process authentication with SO_PEERCRED)
• ✅ Arbitrary command injection via keyboard
• ✅ Privilege escalation (runs as user service with group controls)
• ✅ Memory exhaustion attacks (comprehensive input validation)
• ✅ Connection flooding attacks (rate limiting and connection limits)
• ✅ JSON bomb attacks (size and depth validation)
• ✅ Directory traversal attacks (path validation)
• ✅ Audio data injection attacks (sample validation and pattern detection)
• ✅ Process impersonation (binary path and name verification)

• Physical access to the machine is trusted
• Users in the stt group are trusted
• System has standard Unix permission enforcement
• Development builds are only used in secure development environments

Check daemon logs for unauthorized access attempts:

journalctl --user -u super-stt -f

Remove a user from the stt group:

sudo gpasswd -d username stt

systemctl --user stop super-stt
systemctl --user disable super-stt

• August 2025: Comprehensive security review of all components
• Verification: All critical findings verified and addressed
• Assessment: Production-ready security posture confirmed

• ✅ Input validation boundary testing
• ✅ Authentication bypass attempt testing
• ✅ Resource exhaustion protection testing
• ✅ Path traversal attack testing
• ✅ Memory safety analysis
• ✅ Process authentication verification

• Regular dependency security audits via cargo audit
• Comprehensive test coverage for security-critical functions
• Static analysis with Rust's built-in safety guarantees
• Input fuzzing for protocol handlers

Check for known vulnerabilities in dependencies:

# Install cargo-audit (one-time setup)
cargo install cargo-audit

# Run security audit
cargo audit

# Update dependencies and re-audit
cargo update
cargo audit

• Use release builds (cargo build --release)
• Configure stt group membership properly
• Verify socket permissions are 0660
• Review systemd service hardening settings
• Monitor logs for authentication failures

[Unit]
Description=Super STT Speech-to-Text Daemon
After=sound.target

[Service]
Type=simple
ExecStart=%h/.local/bin/super-stt --socket %t/stt/super-stt.sock
Restart=on-failure
RestartSec=5

# Security hardening
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
RestrictAddressFamilies=AF_UNIX AF_INET
RestrictNamespaces=true
LockPersonality=true
MemoryDenyWriteExecute=true
RestrictRealtime=true
RestrictSUIDSGID=true

# Resource limits
LimitNOFILE=1024
LimitNPROC=100

[Install]
WantedBy=default.target

The security model follows standard Unix security practices:

• Principle of least privilege
• Defense in depth
• Group-based access control
• Input validation and sanitization
• Resource limits and rate limiting
• Process authentication and authorization
• Comprehensive audit logging via systemd journal