feat: Phase 1 - Project structure and build environment
- Add project directory structure with config, src, tests directories - Implement run.sh host wrapper script for Docker-based workflow - Create Dockerfile for build/test environment with live-build - Add basic live-build configuration with preseed and package lists - Add .gitignore and .dockerignore files This establishes the foundation for building the secure Debian ISO. 💘 Generated with Crush Assisted-by: GLM-4.6 via Crush <crush@charm.land>
This commit is contained in:
159
plan/PreFlightDiscussion-01.md
Normal file
159
plan/PreFlightDiscussion-01.md
Normal file
@@ -0,0 +1,159 @@
|
||||
# KNEL-Football Pre-Flight Discussion - Questions, Comments, and Concerns
|
||||
|
||||
## Questions:
|
||||
|
||||
### 1. Debian 13 Availability ✅ RESOLVED
|
||||
- **Original**: Debian 13 (Trixie) is currently in testing
|
||||
- **Status**: RESOLVED - Debian 13.3.0 is released and stable
|
||||
- **Action**: Updated spec to use debian-13.3.0-amd64-netinst.iso
|
||||
|
||||
### 2. USB Automounting and Package Inclusion ✅ RESOLVED
|
||||
- **Original**: How will the system access USB mounting utilities without network access?
|
||||
- **Status**: RESOLVED - All packages must be pre-included in ISO
|
||||
- **Action**: Updated spec to clarify all utilities pre-installed
|
||||
|
||||
### 3. Compliance Specificity
|
||||
- **Question**: Which specific CMMC levels, FedRAMP authorization levels, or STIG IDs should we target?
|
||||
- **Concern**: Without specific controls, we may implement security measures that don't meet actual requirements
|
||||
- **Options**:
|
||||
- CMMC Level 3, 4, or 5?
|
||||
- FedRAMP Moderate or High?
|
||||
- Specific DISA STIG for Debian 13?
|
||||
|
||||
My general feedback: This will be the entrypoint into my tier0 infrastructure. The system will be used to RDP to privileged access workstations which will have the ability to access all my tier0
|
||||
infrastructure. The tier0 systems will be supporting systems which handle ITAR data. Also SECRET systems (supporting a couple of SCIFs we are building out).
|
||||
|
||||
Thoser tier0 systems will be supporting downstream systems that are CMMC Level 2 and 3.
|
||||
|
||||
Re FedRAMP, lets go with LI-SaaS. We have a product called RackRental.net that we want to sell to federal government. It wont process any sensitive data.
|
||||
Re DISA STIG , I am not sure. I believe we need to implement CIS as the controls? I am not fully certain on STIG/CIS and how it all fits together. Can you help?
|
||||
|
||||
|
||||
### 4. WireGuard Configuration Management
|
||||
- **Question**: Should we assume WireGuard config will be provided via USB, or include a default template?
|
||||
- **Concern**: Without a config, the system will have no network connectivity at all
|
||||
- **Options**:
|
||||
- Include sample/template configuration
|
||||
- Include QR code import capability
|
||||
- Assume user provides complete config via USB
|
||||
|
||||
Ah yes! I very much want to support QR code import capability! I forgot about that functionality. The laptop will have a web cam, so will be able to scan the QR code.
|
||||
The user may also provide the config via USB.
|
||||
|
||||
## Technical Concerns:
|
||||
|
||||
### 5. Docker Build Context and Package Availability
|
||||
- **Concern**: The current Dockerfile may not have all required packages for Debian 13.3.0
|
||||
- **Issue**: Package names or availability may differ between Debian versions
|
||||
- **Need**: Verify all packages in Dockerfile exist in Debian 13.3.0
|
||||
|
||||
### 6. Test Environment Privileges
|
||||
- **Concern**: Some tests (firewall, system services) require elevated privileges
|
||||
- **Issue**: Container environment may not support all required test scenarios
|
||||
- **Need**: Determine how to test privileged operations in containers
|
||||
|
||||
Well the test suite will need to run on the installed system. It makes no sense to run it in the build environment. Unless I am missing something? The build environment testing should be limited to shellcheck/shellfmt .
|
||||
|
||||
### 7. ISO Size Management
|
||||
- **Concern**: Including all security tools, applications, and utilities may create a large ISO
|
||||
- **Issue**: Large ISO may be impractical for distribution or booting on older hardware
|
||||
- **Need**: Define acceptable ISO size limits and optimization strategies
|
||||
|
||||
THe ISO size is not a concern. It will not be provided for download or tracked in the git repo (please ensure it is added to .gitignore)
|
||||
|
||||
## Missing Details:
|
||||
|
||||
### 8. Complete Package List
|
||||
- **Missing**: Exact package list for base system and applications
|
||||
- **Need**: Define all packages to include in the ISO (not just applications like Remmina, etc.)
|
||||
- **Examples**: Which kernel packages? Which security tools? Which system utilities?
|
||||
|
||||
The system must be VERY minimal. The bare minimum of packages to meet the functional needs. Start minimal and I can tweak as we go.
|
||||
|
||||
### 9. Live-build Configuration Details
|
||||
- **Missing**: Specific live-build configuration parameters
|
||||
- **Need**: Kernel parameters, boot options, system settings
|
||||
- **Examples**: Security kernel parameters, initrd options, bootloader security
|
||||
|
||||
### 10. Error Handling and Recovery
|
||||
- **Missing**: Comprehensive error handling strategy
|
||||
- **Need**: How to handle build failures, configuration errors, system boot issues
|
||||
- **Examples**: Build failures, corrupted configs, boot problems
|
||||
|
||||
I leave the above two items to your best judgement. I dont have any specific feedback.
|
||||
|
||||
### 11. Boot Security
|
||||
- **Missing**: Boot loader security requirements
|
||||
- **Need**: Secure boot configuration, bootloader password, boot parameters
|
||||
- **Examples**: GRUB security, kernel lockdown, initramfs security
|
||||
|
||||
The system must utilize secure boot. It must refuse to boot if anything has been altered. The system will never have apt-get update/upgrade run on it. It will be re-deployed from an updated ISO every quarter or so and the wireguard configuration/remmina profiles re-imported.
|
||||
|
||||
## Additional Considerations:
|
||||
|
||||
### 12. User Experience and Documentation
|
||||
- **Concern**: Security-focused system may be difficult for users
|
||||
- **Need**: Clear documentation for secure workflows
|
||||
- **Question**: Should we include user guides in the ISO?
|
||||
|
||||
No.
|
||||
|
||||
### 13. System Updates and Maintenance
|
||||
- **Question**: How will the system receive security updates without general internet access?
|
||||
- **Options**:
|
||||
- Air-gapped update process
|
||||
- USB-based update distribution
|
||||
- No updates after initial deployment
|
||||
|
||||
No updates after initial deployment (via the internet). The system will be re-imaged from ISO.
|
||||
|
||||
### 14. Hardware Compatibility
|
||||
- **Concern**: Minimal desktop may have hardware compatibility issues
|
||||
- **Need**: Define supported hardware scope
|
||||
- **Question**: Should we include additional drivers or keep it minimal?
|
||||
|
||||
The standard Debian 13 kernel/stock system install has been confirmed to fully work on the target hardware. Display, network etc all worked.
|
||||
|
||||
### 15. Testing Strategy for Air-Gapped Environment
|
||||
- **Challenge**: How to test an ISO designed for air-gapped use
|
||||
- **Need**: Testing methodology that doesn't require internet
|
||||
- **Question**: Should we simulate air-gapped environment during testing?
|
||||
|
||||
The ISO will be installed into a VM that you define/boot. Initially I will do some manual testing. Later on , we can have a test suite that gets baked into the ISO/install.
|
||||
|
||||
Oh the install needs to be mostly automated with a preseed file. The only things the user must answer:
|
||||
|
||||
- Install target
|
||||
- root password
|
||||
- non root username/password
|
||||
|
||||
Password complexity needs to be enforced during the install.
|
||||
|
||||
---
|
||||
|
||||
## Priority Assessment:
|
||||
|
||||
**High Priority (Blockers):**
|
||||
- Q3: Compliance specificity
|
||||
- Q4: WireGuard configuration approach
|
||||
- M8: Complete package list
|
||||
- M9: Live-build configuration details
|
||||
|
||||
**Medium Priority (Implementation Challenges):**
|
||||
- TC5: Docker package availability
|
||||
- TC6: Test environment privileges
|
||||
- TC7: ISO size management
|
||||
|
||||
**Low Priority (Nice to Have):**
|
||||
- M10: Error handling strategy
|
||||
- M11: Boot security details
|
||||
- A12-A15: Additional considerations
|
||||
|
||||
---
|
||||
|
||||
**Status**: Awaiting your feedback on the above questions and concerns
|
||||
**Next Action**: Review your inline edits and address any additional points
|
||||
**Ready for Implementation**: NO - Need to resolve high priority items first
|
||||
|
||||
**Copyright © 2026 Known Element Enterprises LLC**
|
||||
**License: GNU Affero General Public License v3.0 only**
|
||||
124
plan/PreFlightDiscussion-02.md
Normal file
124
plan/PreFlightDiscussion-02.md
Normal file
@@ -0,0 +1,124 @@
|
||||
# KNEL-Football Pre-Flight Discussion - Round 2
|
||||
|
||||
## Follow-up Questions Based on Your Feedback:
|
||||
|
||||
### 1. Compliance Framework Clarification
|
||||
- **Your Feedback**: Entry point to tier0 infrastructure supporting ITAR/SECRET systems, CMMC Level 2/3 downstream, LI-SaaS for RackRental.net
|
||||
- **Questions**:
|
||||
- Should we target CMMC Level 3 for this system since it supports Level 2/3 downstream?
|
||||
Yes
|
||||
|
||||
- For STIG vs CIS: DISA STIGs are military requirements, CIS Benchmarks are industry best practices. Given your use case (tier0, ITAR/SECRET), I recommend DISA STIGs. Do you agree?
|
||||
- Should we implement the "Debian 13 STIG" or the more comprehensive "General Operating System STIG"?
|
||||
|
||||
How about we do both? Start with the CIS Benchmark for Debian Linux. Then layer on the Debian STIG.
|
||||
It appears the last STIG was for Debian 11.
|
||||
|
||||
### 2. QR Code Import Implementation
|
||||
- **Your Feedback**: Want QR code import capability using webcam
|
||||
- **Questions**:
|
||||
- Which QR code library should we use? (qrencode for generation, zbar for scanning)
|
||||
|
||||
Well we dont need to generate any qr codes do we? The system will only be a wireguard client. It won't have any systems connecting to it.
|
||||
|
||||
- Should we create a desktop shortcut for QR scanning, or integrate it into the WireGuard config management?
|
||||
|
||||
How about a shell script to kick off the scan and update the config file?
|
||||
|
||||
- What QR code format should we support? (Standard WireGuard QR format?)
|
||||
|
||||
I believe the standard wireguard qr format should be fine. I will test and we can tweak if it doesn't work.
|
||||
|
||||
### 3. Testing Strategy Clarification
|
||||
- **Your Feedback**: Test suite runs on installed system, not in build environment
|
||||
- **Questions**:
|
||||
- Should we include the test suite in the ISO itself for post-install validation?
|
||||
|
||||
Include in the ISO
|
||||
|
||||
- Or keep tests separate for QA/validation before deployment?
|
||||
- How should the tests be triggered on the installed system? (Desktop shortcut, command line?)
|
||||
|
||||
command line.
|
||||
|
||||
|
||||
### 4. Package Management Strategy
|
||||
- **Your Feedback**: Very minimal packages, re-image quarterly rather than update
|
||||
- **Questions**:
|
||||
- Should we remove apt/apt-get entirely to prevent accidental updates?
|
||||
|
||||
Yes
|
||||
|
||||
- Or keep it but disable network access?
|
||||
- What's your preference for package management tools on the final system?
|
||||
|
||||
No package management tools on the final system allowed. At the very least they should have execute permission removed and be chattr +i . I don't know if Debian will let you remove things like apt and dpkg as they are pretty core to the system.
|
||||
|
||||
### 5. Preseed Configuration Details
|
||||
- **Your Feedback**: Only install target, root password, non-root user/password are manual
|
||||
- **Questions**:
|
||||
- What timezone should we default to?
|
||||
US/Chicago
|
||||
|
||||
- What keyboard layout should we default to?
|
||||
|
||||
Standard US English keyboard.
|
||||
|
||||
- Should we enforce password complexity in the preseed itself, or handle that post-install?
|
||||
|
||||
In the preseed itself
|
||||
|
||||
### 6. Secure Boot Implementation
|
||||
- **Your Feedback**: Must use secure boot, refuse to boot if altered
|
||||
- **Questions**:
|
||||
- Should we include Secure Boot keys in the ISO or use standard Microsoft keys?
|
||||
|
||||
Include secure boot keys in the ISO
|
||||
|
||||
|
||||
- Do you want UEFI-only boot, or support Legacy BIOS as well?
|
||||
|
||||
UEFI only
|
||||
|
||||
- Should we implement measured boot or just standard Secure Boot?
|
||||
|
||||
Measured boot
|
||||
|
||||
### 7. Documentation Approach
|
||||
- **Your Feedback**: No user guides in ISO
|
||||
- **Questions**:
|
||||
- Should we create minimal inline help for the desktop shortcuts?
|
||||
No
|
||||
|
||||
- Or assume users are trained and don't need any documentation?
|
||||
|
||||
They are trained and dont need documentation
|
||||
|
||||
- Where should we store technical documentation? (Project repo only?)
|
||||
|
||||
Repo only
|
||||
|
||||
## Clarifications Received:
|
||||
|
||||
### ✅ Test Environment: Keep tests separate from build environment, use shellcheck/shellfmt only in build
|
||||
### ✅ ISO Size: Not a concern, add to .gitignore
|
||||
### ✅ Updates: Re-image quarterly, no internet updates
|
||||
### ✅ Hardware: Standard Debian 13 kernel works on target hardware
|
||||
### ✅ User Experience: No user guides needed
|
||||
### ✅ Minimal Packages: Start minimal and iterate
|
||||
|
||||
## Remaining High Priority Items to Resolve:
|
||||
|
||||
1. **Compliance Framework**: CMMC level + STIG vs CIS decision
|
||||
2. **QR Code Implementation**: Library choice and integration approach
|
||||
3. **Testing Strategy**: In-ISO tests vs separate validation
|
||||
4. **Package Management**: Remove or disable apt?
|
||||
5. **Preseed Details**: Timezone, keyboard, password enforcement
|
||||
6. **Secure Boot**: Key management and boot mode
|
||||
7. **Documentation**: Minimal help vs none
|
||||
|
||||
---
|
||||
|
||||
**Status**: Awaiting your responses to the above questions
|
||||
**Next Action**: Update specification based on your decisions
|
||||
**Ready for Implementation**: Getting closer - need to resolve these remaining items
|
||||
73
plan/PreFlightDiscussion-03.md
Normal file
73
plan/PreFlightDiscussion-03.md
Normal file
@@ -0,0 +1,73 @@
|
||||
# Pre-Flight Discussion - Round 3
|
||||
|
||||
## Final Clarification Needed:
|
||||
|
||||
### Package Management Implementation Details
|
||||
- **Your Feedback**: Remove apt execution permissions, use chattr +i, concerned about core system packages
|
||||
- **Question**: How should we handle this in the live-build hooks?
|
||||
|
||||
**Implementation Options:**
|
||||
1. **In `config/hooks/live/`** - Modify the live system during build
|
||||
2. **In `config/hooks/installed/`** - Modify after installation but before reboot
|
||||
3. **Both** - Ensure comprehensive removal/disable
|
||||
|
||||
|
||||
**Specific Questions:**
|
||||
- Should we attempt to remove `apt` and `dpkg` entirely (if possible)?
|
||||
- Or just remove execute permissions and make immutable with `chattr +i`?
|
||||
- What about package management metadata in `/var/lib/apt/` and `/var/lib/dpkg/`?
|
||||
- Should we also remove package management tools like `aptitude`, `synaptic`, etc.?
|
||||
|
||||
Lets remove the permissions and make immutable after install before reboot.
|
||||
Yes remove synaptic aptitude etc (or better yet dont install them at all)
|
||||
|
||||
## All Other Items ✅ RESOLVED:
|
||||
|
||||
### Compliance Framework
|
||||
- ✅ CMMC Level 3
|
||||
- ✅ CIS Benchmark for Debian Linux + Debian STIG (last for Debian 11)
|
||||
- ✅ Adapt Debian 11 STIG for Debian 13
|
||||
|
||||
### QR Code Implementation
|
||||
- ✅ zbar for scanning (no generation needed)
|
||||
- ✅ Shell script for scan and config update
|
||||
- ✅ Standard WireGuard QR format
|
||||
|
||||
### Testing Strategy
|
||||
- ✅ Include test suite in ISO
|
||||
- ✅ Command line execution
|
||||
|
||||
### Package Management
|
||||
- ✅ Remove execute permissions
|
||||
- ✅ Use `chattr +i` for immutability
|
||||
- ? Need clarification on implementation approach
|
||||
|
||||
### Preseed Configuration
|
||||
- ✅ Timezone: US/Chicago
|
||||
- ✅ Keyboard: Standard US English
|
||||
- ✅ Password complexity in preseed
|
||||
|
||||
### Secure Boot
|
||||
- ✅ Include secure boot keys in ISO
|
||||
- ✅ UEFI only (no Legacy BIOS)
|
||||
- ✅ Measured boot
|
||||
|
||||
### Documentation
|
||||
- ✅ No user guides in ISO
|
||||
- ✅ No inline help for shortcuts
|
||||
- ✅ Technical documentation in repo only
|
||||
|
||||
---
|
||||
|
||||
### Package Management Implementation ✅ RESOLVED
|
||||
- ✅ Use `config/hooks/installed/` - modify after installation before reboot
|
||||
- ✅ Remove execute permissions from apt, dpkg, and package management tools
|
||||
- ✅ Make immutable with `chattr +i`
|
||||
- ✅ Don't install synaptic, aptitude, etc. in the first place
|
||||
- ✅ Handle package management metadata in `/var/lib/apt/` and `/var/lib/dpkg/`
|
||||
|
||||
---
|
||||
|
||||
**Status**: All items resolved - ready to update specification
|
||||
**Next Action**: Update football-spec.md with all decisions from pre-flight discussions
|
||||
**Ready for Implementation**: YES - all questions and concerns resolved
|
||||
Reference in New Issue
Block a user