football/docs/security-model.md

KNEL-Football Security Model

Overview

The KNEL-Football security model implements a defense-in-depth approach to create a highly secure, compliant Debian 13 operating system for tier0 infrastructure access.

Copyright © 2026 Known Element Enterprises LLC License: GNU Affero General Public License v3.0 only

Security Architecture

Core Principles

1. Least Privilege - Users and processes have only necessary permissions
2. Defense in Depth - Multiple layers of security controls
3. Zero Trust - No implicit trust, all access must be authorized
4. Immutability - System configuration is not easily modifiable
5. Minimal Attack Surface - Only necessary services and packages included

System Hardening Layers

1. Boot Security Layer

• UEFI-Only Boot - No legacy BIOS support prevents boot attacks
• Secure Boot - Cryptographic verification of bootloader and kernel
• Unified Kernel Image (UKI) - Signed kernel+initramfs+cmdline bundle
• Kernel Lockdown - Kernel runs in confidentiality lockdown mode
• Measured Boot - Boot chain integrity measurement and attestation

Secure Boot Trust Chain

┌─────────────────────────────────────────────────────────────────────────────┐
│                        SECURE BOOT TRUST CHAIN                               │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│  ┌─────────────────────┐                                                    │
│  │   UEFI Firmware     │  ← Root of Trust (Hardware)                       │
│  └──────────┬──────────┘                                                    │
│             │ Verifies PK signature                                         │
│             ▼                                                               │
│  ┌─────────────────────┐                                                    │
│  │  PK (Platform Key)  │  ← RSA-4096, SHA-256, 3650 days                   │
│  │    Self-signed      │     Platform owner authorization                   │
│  └──────────┬──────────┘                                                    │
│             │ Signs KEK updates                                             │
│             ▼                                                               │
│  ┌─────────────────────┐                                                    │
│  │ KEK (Key Exchange)  │  ← RSA-4096, SHA-256, 3650 days                   │
│  │   Signed by PK      │     OS/key exchange authorization                  │
│  └──────────┬──────────┘                                                    │
│             │ Signs db updates                                              │
│             ▼                                                               │
│  ┌─────────────────────┐                                                    │
│  │ db (Signature DB)   │  ← RSA-4096, SHA-256, 3650 days                   │
│  │  Signed by KEK      │     Allowed EFI binaries                           │
│  └──────────┬──────────┘                                                    │
│             │ Verifies UKI signature                                        │
│             ▼                                                               │
│  ┌─────────────────────┐                                                    │
│  │   UKI (Unified      │  ← Signed EFI binary                              │
│  │   Kernel Image)     │     • linuxx64.efi.stub                           │
│  │                     │     • os-release                                  │
│  │                     │     • cmdline (lockdown=confidentiality)          │
│  │                     │     • linux (vmlinuz)                             │
│  │                     │     • initrd (initramfs)                          │
│  └──────────┬──────────┘                                                    │
│             │ Boots with lockdown                                           │
│             ▼                                                               │
│  ┌─────────────────────┐                                                    │
│  │   Linux Kernel      │  ← Kernel Lockdown Mode                           │
│  │   (Confidentiality) │     • module.sig_enforce=1                        │
│  │                     │     • No unsigned modules                         │
│  │                     │     • No /dev/mem access                          │
│  │                     │     • No kexec                                    │
│  └─────────────────────┘                                                    │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

Secure Boot Keys

Key	Purpose	Algorithm	Validity
PK (Platform Key)	Authorizes KEK updates	RSA-4096, SHA-256	3650 days
KEK (Key Exchange Key)	Authorizes db updates	RSA-4096, SHA-256	3650 days
db (Signature Database)	Signs EFI binaries	RSA-4096, SHA-256	3650 days

UKI Components

Section	Content	Purpose
.osrel	/etc/os-release	OS identification
.cmdline	Kernel parameters	lockdown=confidentiality, module.sig_enforce=1
.linux	vmlinuz-{version}	Kernel image
.initrd	initrd.img-{version}	Initial ramdisk

Kernel Lockdown Effects

When Secure Boot is active and kernel lockdown is enabled:

• No unsigned kernel modules - module.sig_enforce=1
• No /dev/mem or /dev/kmem access - Prevents direct memory manipulation
• No kexec - Cannot replace running kernel
• No hibernation to untrusted storage - Prevents data extraction
• No iopl/ioperm - Restricts I/O port access
• No MSRs from userspace - Restricts model-specific register access

Secure Boot Enforcement

• Build Time: Keys generated, UKI signed during ISO build
• Install Time: Keys enrolled in UEFI firmware (setup mode)
• Boot Time: UEFI verifies UKI signature before boot
• Runtime: Kernel enforces lockdown mode restrictions

2. Network Security Layer

• Network Isolation - No general internet access
• VPN-Only Access - WireGuard tunnel required for all network traffic
• Firewall Hardening - Default deny policy with specific rules
• Wireless Disabled - WiFi and Bluetooth permanently disabled
• Dynamic Configuration - Firewall rules adapt to WireGuard endpoints

3. System Security Layer

• Kernel Module Blacklisting - Prevents loading of dangerous modules
• Service Hardening - Unnecessary services disabled
• Process Isolation - Application sandboxing where applicable
• Resource Limits - Prevent resource exhaustion attacks
• Audit Logging - Comprehensive system activity monitoring

4. Access Control Layer

• Strong Authentication - 14-character minimum password policy
• No Auto-Login - Manual authentication required
• Privacy Mode - Usernames hidden in display manager
• Sudo Configuration - Controlled administrative access
• File Permissions - Secure access controls on sensitive files

5. Application Security Layer

• Minimal Desktop - IceWM provides minimal attack surface
• Required Applications Only - Only essential tools included
• Secure Defaults - Applications configured with secure settings
• No Package Management - System immutability through disabled package tools

Threat Model

Adversary Capabilities

Capability	Mitigation	Effectiveness
Network-based attacks	Network isolation, firewall	High
Local privilege escalation	User permissions, audit	Medium
Physical access attacks	Encryption, secure boot	High
Social engineering	Training, documentation	Medium
Supply chain attacks	Source verification, testing	Medium

Attack Scenarios

Scenario 1: Network-based Attack

Attack: Attempt to compromise system via network connection Mitigation:

• No general network access available
• Only WireGuard tunnel traffic allowed
• Firewall default deny policy
• Dynamic endpoint-based rules

Scenario 2: USB-based Attack

Attack: Malicious USB device inserted Mitigation:

• USB devices mounted with restrictive permissions
• No auto-execution from removable media
• Filesystem permissions restrict access
• Audit logging tracks USB activity

Scenario 3: Local Privilege Escalation

Attack: User attempts to gain root privileges Mitigation:

• Strong password policies
• Sudo configuration with restrictions
• Audit logging tracks privilege usage
• System resource limits

Scenario 4: System Modification

Attack: Attempt to modify system configuration Mitigation:

• Package management disabled
• Critical system files have immutable attributes
• Audit logging tracks configuration changes
• Regular compliance checks

Security Controls

Preventive Controls

1. Network Controls

   • Module blacklisting for WiFi/Bluetooth
   • Default deny firewall configuration
   • VPN-only network access
   • USB device restrictions

2. System Controls

   • Service hardening and disabling
   • Strong authentication policies
   • File permission hardening
   • System resource limits

3. Boot Controls

   • UEFI-only boot mode
   • Secure Boot verification
   • Measured boot attestation

Detective Controls

1. Logging and Monitoring

   • Comprehensive audit daemon configuration
   • System event logging
   • Network traffic logging
   • User activity tracking

2. Compliance Validation

   • Automated compliance checks
   • Security configuration verification
   • Regular security assessments
   • Vulnerability scanning

Corrective Controls

1. Incident Response
   • Automated alerting on security events
   • Isolation capabilities
   • System recovery procedures
   • Forensic preservation

Risk Assessment

High-Risk Areas

1. USB Device Handling - Medium Risk

   • Mitigation: Restrictive mounting, no auto-execution
   • Residual Risk: Low

2. Physical Access - Medium Risk

   • Mitigation: Full disk encryption, secure boot
   • Residual Risk: Low

3. VPN Configuration - Medium Risk

   • Mitigation: Encrypted configuration, authentication
   • Residual Risk: Low

Low-Risk Areas

1. Network-based Attacks - Low Risk

   • Mitigation: Complete network isolation
   • Residual Risk: Minimal

2. Remote Exploitation - Low Risk

   • Mitigation: Minimal services, firewall
   • Residual Risk: Minimal

Security Validation

Testing Methodology

1. Unit Testing - Individual security function validation
2. Integration Testing - End-to-end security workflow testing
3. Penetration Testing - External security assessment
4. Compliance Testing - Automated validation against standards

Validation Metrics

1. Coverage Metrics - 100% of security controls tested
2. Compliance Metrics - 100% compliance with frameworks
3. Vulnerability Metrics - Zero critical vulnerabilities
4. Configuration Metrics - 100% secure configuration validation

Continuous Security

Maintenance

1. Security Updates - Through controlled ISO rebuilds
2. Configuration Changes - Through verified, version-controlled updates
3. Compliance Monitoring - Continuous compliance validation
4. Security Monitoring - Real-time security event analysis

Improvement

1. Threat Intelligence - Regular threat model updates
2. Security Assessments - Periodic security reviews
3. Testing Enhancement - Continuous test suite improvement
4. Documentation Updates - Regular security documentation revision

---

Copyright © 2026 Known Element Enterprises LLC License: GNU Affero General Public License v3.0 only

This security model is maintained as part of the KNEL-Football project and is updated when security requirements change or new threats emerge.