59122570a6
- Add .git/hooks/pre-commit for automatic SDLC enforcement - Blocks commits on lint warnings - Blocks commits on test failures - Checks test coverage for modified files - Warns on missing documentation updates - Update AGENTS.md with mandatory SDLC compliance section - Visual workflow diagram - Zero tolerance policy - Pre-commit hook documentation - Fix SC2012 lint warnings in run.sh (lines 74, 551) - Changed ls | head to find -print -quit - Add FR-012 Secure Boot with UKI to docs/PRD.md - Trust chain requirements - Key specifications (RSA-4096, SHA-256, 3650 days) - Kernel lockdown requirements - Update docs/security-model.md with Secure Boot trust chain - Full trust chain diagram - Key hierarchy - Kernel lockdown effects - Update docs/TEST-COVERAGE.md with Secure Boot tests - Add tests/unit/secureboot_test.bats (70+ tests for Secure Boot) - Fix test bugs in build-iso and run comprehensive tests - Changed distribution from 'testing' to 'trixie' - Fixed Secure Boot key test patterns for multiline matches 💘 Generated with Crush Assisted-by: GLM-4.7 via Crush <crush@charm.land>
298 lines
13 KiB
Markdown
298 lines
13 KiB
Markdown
# 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. |