football/docs/audit/2026-02-20/findings.md

KNEL-Football Secure OS - Security Audit Report

Date: 2026-02-20 Auditor: External Security Auditor Scope: Comprehensive security and QA review Classification: CONFIDENTIAL

---

Executive Summary

Overall Assessment: The KNEL-Football Secure OS project demonstrates a mature security posture with strong architectural foundations. The project shows evidence of security-first thinking, comprehensive documentation, and automated enforcement mechanisms. However, several areas require attention before production deployment.

Risk Summary

Severity	Count	Areas
Critical	0	-
High	2	Secure Boot key management, Firewall output policy
Medium	4	Docker privileged mode, USB automount, Argon2 KDF config, Supply chain
Low	3	Test coverage gaps, Hadolint warnings, Documentation sync
Informational	5	Various observations

Key Strengths

1. Strong SDLC Enforcement: Pre-commit hooks enforce TDD, linting, and test coverage
2. Comprehensive Encryption: LUKS2 with AES-256-XTS-512, proper passphrase validation
3. Defense in Depth: Multiple security layers (FDE, firewall, audit, FIM, hardening)
4. No SSH Server: Correctly implements client-only SSH per PRD FR-006
5. Clean Shellcheck: All scripts pass shellcheck with zero warnings
6. Host FDE Enforcement: Build system refuses to run without host encryption

Areas Requiring Attention

1. Secure Boot Key Management: Keys generated at build time without HSM or secure storage
2. USB Automount: Security risk for a secure workstation
3. Supply Chain: No SLSA/SBOM, unpinned Docker packages

Note: The strict firewall OUTPUT policy (FINDING-002) was confirmed as intentional design for an immutable system with zero traffic leakage.

---

Detailed Findings

FINDING-001: Secure Boot Key Management (HIGH)

Category: Cryptographic Key Management Severity: HIGH Status: Open

Description: Secure Boot keys (PK, KEK, db) are generated at ISO build time using OpenSSL with self-signed certificates. The private keys are stored in the build directory and potentially embedded in the ISO.

Location:

• run.sh:441-484 - sb_generate_keys() function
• run.sh:455-472 - OpenSSL key generation commands

Code Examined:

openssl req -new -x509 -newkey rsa:4096 -sha256 -days 3650 \
    -nodes -subj "/CN=KNEL-Football PK/" \
    -keyout "${SB_KEY_DIR}/PK.key" \
    -out "${SB_KEY_DIR}/PK.crt" 2>/dev/null

Issues:

1. Keys generated on every build with no persistence or secure storage
2. Private keys could be exposed in build artifacts
3. No Hardware Security Module (HSM) integration
4. 10-year validity without rotation policy
5. No key escrow or recovery mechanism
6. Subject DN uses generic CN without organization identification

Risk: An attacker with build system access could extract private keys and sign malicious bootloaders.

Recommendation:

1. Pre-generate keys offline and store in HSM or air-gapped secure storage
2. Only embed public keys/certificates in the ISO
3. Implement key rotation policy
4. Add key provenance documentation
5. Consider using a commercial PKI for production deployments

Compliance Impact: NIST SP 800-57, FedRAMP SC-12

---

FINDING-002: Firewall Output Chain Default DROP (INFORMATIONAL - BY DESIGN)

Category: Network Security Severity: INFORMATIONAL Status: By Design - No Action Required

Description: The nftables firewall configuration sets a default DROP policy on the OUTPUT chain, only allowing loopback, WireGuard traffic, and ICMP ping.

Location:

• src/firewall-setup.sh:43-47 - Output chain rules
• config/hooks/live/firewall-setup.sh:29-34 - Live hook output rules

Code Examined:

chain output {
    type filter hook output priority 0; policy drop
    oif lo accept comment "Accept loopback"
    udp dport "$port" ip daddr "$ip" accept comment "Allow WireGuard traffic"
    icmp type echo-request accept comment "Allow ping"
}

Clarification from Project Team: This is an intentional design choice for an immutable system security model:

1. Zero Traffic Leakage: No DNS, no NTP, no HTTP/HTTPS - eliminates DNS poisoning, NTP spoofing, and C2 exfiltration vectors
2. Immutable System: Package management disabled, no in-place updates - CVEs handled by regenerating ISO and recreating VM
3. WireGuard via USB: Endpoint IP loaded from wg0.conf on USB disk at provisioning time
4. Time from Host: VM receives time from hypervisor/host system, no network time sync needed
5. Known Endpoints: WireGuard peer IP is static and pre-configured

Assessment: This is a defensible security posture for an air-gapped, immutable access terminal. The strict OUTPUT DROP policy prevents:

• Data exfiltration via DNS tunneling
• C2 beacon traffic
• Supply chain attacks via compromised update servers
• NTP-based attacks

Recommendation: Document this design decision in the security model documentation for future auditors.

Compliance Impact: NIST SP 800-41, CIS Benchmark 3.x - Compensating controls in place (immutable system, no package management)

---

FINDING-003: Docker Privileged Mode (MEDIUM)

Category: Build Security Severity: MEDIUM Status: Open

Description: The ISO build process runs Docker with --privileged flag.

Location:

• run.sh:979 - Docker run command

Code Examined:

docker run --rm --privileged \
    -v "${SCRIPT_DIR}:/workspace:ro" \
    ...

Issues:

1. Privileged containers have full access to host devices
2. Could allow container escape if build process compromised
3. live-build requires privileged mode for loop device access

Risk: If the build environment is compromised, attacker could escape to host.

Mitigating Factors:

1. Build runs in isolated environment (documented requirement)
2. Build artifacts are read-only mounted
3. Pre-commit hooks validate code before build

Recommendation:

1. Document the security implications of privileged mode
2. Consider using rootless Docker or podman
3. Implement build environment attestation
4. Consider using dedicated build infrastructure

---

FINDING-004: USB Automount Enabled (MEDIUM)

Category: Endpoint Security Severity: MEDIUM Status: Open

Description: The system automatically mounts USB storage devices when connected.

Location:

• config/hooks/live/usb-automount.sh - Entire file

Code Examined:

cat >/etc/udev/rules.d/99-usb-automount.rules <<'EOF'
ACTION=="add", SUBSYSTEM=="block", ENV{ID_FS_USAGE}=="filesystem", RUN+="/usr/local/bin/usb-automount.sh %k"

Issues:

1. Automatic mounting of untrusted media is a security risk
2. BadUSB attacks could compromise the system
3. USB devices could exfiltrate data
4. Conflicts with "secure workstation" threat model

Risk: Physical access attack vector via malicious USB devices.

Recommendation:

1. Disable USB automount by default
2. Implement USB device authorization (usbguard)
3. Consider blocking USB storage entirely for tier0 access
4. If USB required, implement manual mount-only policy

Compliance Impact: CIS Benchmark 1.1.x, NIST SP 800-53 AC-19

---

FINDING-005: Argon2id KDF Not Explicitly Configured (MEDIUM)

Category: Encryption Severity: MEDIUM Status: Open

Description: The PRD specifies Argon2id KDF for LUKS2, but the preseed.cfg does not explicitly configure it.

Location:

• config/includes.installer/preseed.cfg:111-116 - LUKS configuration
• docs/PRD.md - FR-001 requirement

Code Examined:

d-i partman-crypto/cipher aes-xts-plain64
d-i partman-crypto/keysize 512
d-i partman-crypto/use-luks2 boolean true

Issues:

1. No explicit Argon2id configuration in preseed
2. Debian partman-crypto defaults may use PBKDF2
3. Documentation claims Argon2id but implementation unclear

Risk: If PBKDF2 is used instead of Argon2id, weaker key derivation against brute-force.

Recommendation:

1. Add explicit d-i partman-crypto/keyscript or post-install hook to enforce Argon2id
2. Verify actual KDF in use after installation
3. Add test to validate LUKS header uses Argon2id

Verification Required: Install system and run cryptsetup luksDump to verify KDF.

---

FINDING-006: Unpinned Docker Packages (MEDIUM)

Category: Supply Chain Severity: MEDIUM Status: Open

Description: Dockerfile does not pin package versions, using apt-get install <package> instead of <package>=<version>.

Location:

• Dockerfile:16, 29, 45, 55 - apt-get install commands

Hadolint Output:

-:16 DL3008 warning: Pin versions in apt get install
-:29 DL3008 warning: Pin versions in apt get install
-:45 DL3008 warning: Pin versions in apt get install
-:55 DL3008 warning: Pin versions in apt get install

Issues:

1. Non-reproducible builds - different package versions on different days
2. Cannot verify exact software supply chain
3. Security updates may introduce regressions

Recommendation:

1. Pin all package versions in Dockerfile
2. Generate SBOM (Software Bill of Materials) during build
3. Consider SLSA compliance for supply chain security
4. Document package version freeze policy

---

FINDING-007: Test Coverage Gaps (LOW)

Category: Quality Assurance Severity: LOW Status: Open

Description: Test coverage documentation claims 562 tests, but several areas have minimal testing.

Location:

• tests/unit/encryption-validation_test.bats - Only 4 tests
• Various unit tests are text-based (grep for strings) not functional

Issues:

1. encryption-validation_test.bats has only 4 tests
2. Many tests verify text presence rather than behavior
3. No integration tests for actual LUKS encryption
4. Firewall tests mock rather than execute nft

Examples:

# Weak test - only checks for string presence
@test "Validation checks for LUKS2 format" {
    grep -q "LUKS\|luks" /workspace/config/hooks/installed/encryption-validation.sh
}

Recommendation:

1. Increase functional test coverage
2. Add integration tests with actual cryptsetup operations
3. Test firewall rules with nft --check
4. Document test coverage gaps

---

FINDING-008: Documentation-Code Synchronization (LOW)

Category: Documentation Severity: LOW Status: Open

Description: Some discrepancies between documentation and implementation.

Issues:

1. PRD specifies Argon2id, preseed doesn't configure it explicitly
2. PRD FR-005 says WiFi/Bluetooth "permanently disabled", but modules can be reloaded by root
3. User account inconsistency: preseed creates "football" user, hooks reference "kneluser"

Location:

• config/includes.installer/preseed.cfg:38 - User "football"
• config/hooks/installed/encryption-validation.sh:106 - Path "/home/kneluser"

Recommendation:

1. Add documentation validation to CI
2. Create user account consistency test
3. Document the difference between "disabled" and "blacklisted" modules

---

FINDING-009: QR Code Scanner Command Injection Risk (LOW)

Category: Input Validation Severity: LOW Status: Open

Description: The QR code import script parses untrusted input from QR codes and processes it with Python.

Location:

• config/hooks/live/qr-code-import.sh:48-76 - Python QR parsing

Issues:

1. QR data is untrusted input
2. Python script does minimal validation
3. Could potentially inject malicious config values

Mitigating Factors:

1. Script runs as user (pkexec for elevation)
2. WireGuard config has limited attack surface
3. Physical access required to present QR code

Recommendation:

1. Add strict input validation in Python script
2. Sanitize all parsed values before writing config
3. Add length limits on QR data
4. Log all QR imports for audit trail

---

FINDING-010: Package Management Disabled Aggressively (INFORMATIONAL)

Category: System Administration Severity: INFORMATIONAL Status: Informational

Description: Package management is disabled by removing execute permissions and making directories immutable.

Location:

• config/hooks/installed/disable-package-management.sh

Code Examined:

chmod -x /usr/bin/apt /usr/bin/apt-get /usr/bin/dpkg
chattr +i /usr/bin/apt /usr/bin/apt-get /usr/bin/dpkg
rm -rf /var/lib/apt/* /var/lib/dpkg/*

Observations:

1. Effective at preventing package installation
2. Makes security updates impossible without recovery
3. Consider document update procedure for security patches

Recommendation: Document the security patching procedure for deployed systems.

---

Positive Observations

OBSERVATION-001: Strong Pre-Commit Enforcement

The pre-commit hook enforces SDLC requirements including linting, testing, and coverage checks. This is excellent security practice.

OBSERVATION-002: No Hardcoded Credentials

No hardcoded passwords, API keys, or secrets found in the codebase. Password prompts are forced during installation.

OBSERVATION-003: Comprehensive Audit Rules

The auditd configuration is thorough and covers security-critical files and operations.

OBSERVATION-004: SSH Client Only

Correctly implements client-only SSH (no sshd installed) per PRD FR-006.

OBSERVATION-005: Host FDE Enforcement

Build system validates host encryption before allowing ISO builds - prevents data leakage via build artifacts.

---

Compliance Matrix

Standard	Requirement	Status
NIST SP 800-53 SC-8	Transmission Confidentiality	✅ WireGuard
NIST SP 800-53 SC-12	Cryptographic Key Management	⚠️ See FINDING-001
NIST SP 800-53 AC-19	Access Control for Mobile Devices	⚠️ See FINDING-004
NIST SP 800-111	Storage Encryption	✅ LUKS2
CIS Benchmark 1.x	Filesystem Configuration	⚠️ USB automount
CIS Benchmark 6.x	Logging and Auditing	✅ Comprehensive audit
FedRAMP SC-7	Boundary Protection	⚠️ See FINDING-002

---

Recommendations Summary

Immediate (Before Release)

1. Review and fix firewall OUTPUT chain policy (FINDING-002)
2. Decide on USB automount policy (FINDING-004)
3. Verify Argon2id KDF is actually used (FINDING-005)

Short-term (30 days)

1. Implement Secure Boot key management plan (FINDING-001)
2. Pin Docker package versions (FINDING-006)
3. Add functional integration tests (FINDING-007)

Long-term (90 days)

1. Consider SLSA/SBOM implementation
2. Implement USB authorization (usbguard)
3. Add build environment attestation

---

Conclusion

The KNEL-Football Secure OS project demonstrates strong security fundamentals with comprehensive encryption, hardening, and audit capabilities. The SDLC enforcement through pre-commit hooks is exemplary.

The primary concerns relate to:

1. Secure Boot key management (keys generated at build time)
2. Firewall configuration that may break essential services
3. USB automount conflicting with the security model

With the recommended fixes, this project would be suitable for tier0 infrastructure access in compliance-focused environments.

Signed: External Security Auditor Date: 2026-02-20