Two levels of pure taxonomy carrying no information, and a 2-directory
cap leaves no room for them. Categories now sit directly under
linux_configuration/: features, fixes, utils, misc, fresh-install,
installers, diagnostics, gaming, boot_recovery, periodic_background, lib,
meta, tests. A script's own lib/ and tests/ are exempt from the cap, so
those stay put.
Depth violations 248 -> 139; roughly 40 of the remainder are inside
digital_wellbeing and hosts, deferred until the guard-lib repoint.
The moves are the easy half. What breaks is every path that counted
levels, and three classes of it had to be found by resolving paths rather
than reading diffs:
- 52 relative `source` lines for lib/common.sh and lib/android.sh. The
correct prefix differs per file: 40 were ../../ and 12 were ../../../,
so a blanket replace would have fixed one set and broken the other.
- REPO_ROOT in 7 fixes/lib/tests harnesses and setup_syncyomi_guard.sh,
each walking up four levels from a directory now two levels shallower.
This caused a real regression -- the fixes suite went red with
"log_warn: command not found" -- caught by running it and comparing
against the pre-move baseline worktree.
- conftest.py's sys.path entries, which took the pytest gate down with
14 collection errors, and the `# shellcheck source=` directives, which
took shellcheck down with SC1091.
16 symlinks in $HOME broke, including the entire i3blocks bar. All
repointed, and cpu_monitor/memory/disk/time/volume were run to confirm
they emit real output rather than merely resolving.
Verified: 1798 tests pass at 100% coverage, 8 of 9 lib/tests suites pass
(the ninth needs the coverage jail, identically at baseline), pre-commit
is clean, and the two untracked secret configs are still ignored after
their gitignore paths changed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJrqKERAo5QUeEHWS5Asgp
5.4 KiB
Pacman Wrapper Security Enhancements
Overview
This document describes the security enhancements made to the pacman wrapper to prevent circumvention, particularly for VirtualBox installations.
Problem Statement
The original pacman wrapper had the following vulnerabilities:
- Easy Policy Bypass: Users could edit
pacman_greylist.txtorpacman_blocked_keywords.txtto remove restrictions, then reinstall the wrapper. - VirtualBox Hosts Bypass: VirtualBox VMs do not inherit the host machine's
/etc/hostsfile, allowing users to bypass content filtering within VMs. - No Tamper Detection: The wrapper had no mechanism to detect if policy files had been modified.
Solutions Implemented
1. Policy File Integrity Checks
File: periodic_background/digital_wellbeing/pacman/install_pacman_wrapper.sh
The installer now:
- Generates SHA256 checksums of all policy files during installation
- Stores checksums in
/var/lib/pacman-wrapper/policy.sha256 - Makes the integrity file immutable using
chattr +i - Makes policy files (
pacman_blocked_keywords.txt,pacman_greylist.txt) immutable
File: periodic_background/digital_wellbeing/pacman/pacman_wrapper.sh
The wrapper now:
- Verifies policy file integrity on every invocation
- Compares current file checksums against stored checksums
- Blocks all operations if tampering is detected
- Displays security warnings and instructs user to reinstall
Benefits:
- Cannot bypass restrictions by editing policy files
- Tampering is immediately detected and blocked
- Must use
chattr -i(requires root) to modify files, making bypass harder
2. Hardcoded VirtualBox Restrictions
File: periodic_background/digital_wellbeing/pacman/pacman_wrapper.sh
Added hardcoded VirtualBox detection that cannot be bypassed by editing policy files:
function is_virtualbox_package() {
local pkg_lower="${1,,}"
[[ $pkg_lower == *"virtualbox"* || $pkg_lower == *"vbox"* ]]
}
This function:
- Is compiled into the wrapper code itself
- Cannot be disabled by editing text files
- Catches all VirtualBox-related packages
Enhanced Challenge:
- 7-letter words (harder than greylist's 6-letter words)
- 150 words to memorize (more than greylist's 120)
- 120-second timeout (longer than greylist's 90s)
- 45-second initial delay (psychological friction)
- 30-50 second post-challenge delay
Warning Messages:
- Explicit warning about /etc/hosts bypass potential
- Lists security measures that will be applied
- Emphasizes that restrictions are hardcoded
3. VirtualBox Hosts Enforcement
File: periodic_background/digital_wellbeing/virtualbox/enforce_vbox_hosts.sh
A new enforcement script that:
For Host Configuration:
- Configures all VMs to use host's DNS resolution (
--natdnshostresolver1 on) - Enables NAT DNS proxy (
--natdnsproxy1 on) - Adds
/etcas a read-only shared folder to all VMs - Tracks enforcement status with marker file
For Guest Configuration:
- Generates a startup script for VMs
- Mounts the shared
/etcfolder inside the VM - Syncs host's
/etc/hoststo VM's/etc/hosts - Makes the hosts file read-only in the VM
Commands:
# Apply enforcement to all VMs
sudo enforce_vbox_hosts.sh enforce
# Check enforcement status
sudo enforce_vbox_hosts.sh status
# Generate script for VM guests
sudo enforce_vbox_hosts.sh generate-script
Auto-Integration: The pacman wrapper automatically:
- Detects VirtualBox installation after any install operation
- Locates and runs the enforcement script
- Applies enforcement to all existing VMs
- Creates enforcement marker to avoid repeated runs
4. Installation Integration
File: periodic_background/digital_wellbeing/pacman/install_pacman_wrapper.sh
The installer now:
- Installs VirtualBox enforcement script to
/usr/local/share/digital_wellbeing/virtualbox/ - Makes the enforcement script executable
- Reports installation status to user
Security Guarantees
What's Protected
-
Policy files cannot be easily modified:
- Immutable attribute prevents casual editing
- Requires
chattr -iwhich requires root and knowledge - Changes are detected on next wrapper invocation
-
VirtualBox restrictions are hardcoded:
- Cannot remove by editing policy files
- Would require modifying the wrapper code itself
- Integrity checks would detect wrapper modification
-
VMs inherit host's content filtering:
- DNS queries use host's resolution
- /etc/hosts is synced from host to guest
- Read-only mounting prevents VM modification
What's Still Vulnerable
-
Root access can bypass everything:
- Root can
chattr -iand modify files - Root can edit the wrapper script itself
- Root can disable enforcement entirely
- Mitigation: Not the goal; this is about self-discipline, not security against root
- Root can
-
Wrapper replacement:
- Could replace
/usr/bin/pacmanwith direct link to/usr/bin/pacman.orig - Mitigation: Periodic maintenance services can detect and alert
- Reinstallation would fail integrity check if files are modified
- Could replace
-
VM Guest Additions bypass:
- If guest doesn't install VBox Guest Additions, shared folders won't work
- Mitigation: DNS proxy still enforces host's DNS resolution
- Manual hosts file sync would be needed
More detail
Split out to stay under the 250-line cap.