fix(security): complete SSRF remediation with defense-in-depth (CWE-918)

.docker/docker-entrypoint.sh

@@ -30,6 +30,36 @@ mkdir -p /app/data/caddy 2>/dev/null || true
 mkdir -p /app/data/crowdsec 2>/dev/null || true
 mkdir -p /app/data/geoip 2>/dev/null || true
 
+# ============================================================================
+# Docker Socket Permission Handling
+# ============================================================================
+# The Docker integration feature requires access to the Docker socket.
+# This section runs as root to configure group membership, then privileges
+# are dropped to the charon user at the end of this script.
+
+if [ -S "/var/run/docker.sock" ]; then
+    DOCKER_SOCK_GID=$(stat -c '%g' /var/run/docker.sock 2>/dev/null || echo "")
+    if [ -n "$DOCKER_SOCK_GID" ] && [ "$DOCKER_SOCK_GID" != "0" ]; then
+        # Check if a group with this GID exists
+        if ! getent group "$DOCKER_SOCK_GID" >/dev/null 2>&1; then
+            echo "Docker socket detected (gid=$DOCKER_SOCK_GID) - creating docker group and adding charon user..."
+            # Create docker group with the socket's GID
+            addgroup -g "$DOCKER_SOCK_GID" docker 2>/dev/null || true
+            # Add charon user to the docker group
+            addgroup charon docker 2>/dev/null || true
+            echo "Docker integration enabled for charon user"
+        else
+            # Group exists, just add charon to it
+            GROUP_NAME=$(getent group "$DOCKER_SOCK_GID" | cut -d: -f1)
+            echo "Docker socket detected (gid=$DOCKER_SOCK_GID, group=$GROUP_NAME) - adding charon user..."
+            addgroup charon "$GROUP_NAME" 2>/dev/null || true
+            echo "Docker integration enabled for charon user"
+        fi
+    fi
+else
+    echo "Note: Docker socket not found. Docker container discovery will be unavailable."
+fi
+
 # ============================================================================
 # CrowdSec Initialization
 # ============================================================================
@@ -43,10 +73,12 @@ if command -v cscli >/dev/null; then
     CS_PERSIST_DIR="/app/data/crowdsec"
     CS_CONFIG_DIR="$CS_PERSIST_DIR/config"
     CS_DATA_DIR="$CS_PERSIST_DIR/data"
+    CS_LOG_DIR="/var/log/crowdsec"
 
     # Ensure persistent directories exist (within writable volume)
     mkdir -p "$CS_CONFIG_DIR" 2>/dev/null || echo "Warning: Cannot create $CS_CONFIG_DIR"
     mkdir -p "$CS_DATA_DIR" 2>/dev/null || echo "Warning: Cannot create $CS_DATA_DIR"
+    mkdir -p "$CS_PERSIST_DIR/hub_cache"
     # Log directories are created at build time with correct ownership
     # Only attempt to create if they don't exist (first run scenarios)
     mkdir -p /var/log/crowdsec 2>/dev/null || true
@@ -55,20 +87,33 @@ if command -v cscli >/dev/null; then
     # Initialize persistent config if key files are missing
     if [ ! -f "$CS_CONFIG_DIR/config.yaml" ]; then
         echo "Initializing persistent CrowdSec configuration..."
-        if [ -d "/etc/crowdsec.dist" ]; then
-            cp -r /etc/crowdsec.dist/* "$CS_CONFIG_DIR/" 2>/dev/null || echo "Warning: Could not copy dist config"
-        elif [ -d "/etc/crowdsec" ] && [ ! -L "/etc/crowdsec" ]; then
-            # Fallback if .dist is missing
-            cp -r /etc/crowdsec/* "$CS_CONFIG_DIR/" 2>/dev/null || echo "Warning: Could not copy config"
+        if [ -d "/etc/crowdsec.dist" ] && [ -n "$(ls -A /etc/crowdsec.dist 2>/dev/null)" ]; then
+            cp -r /etc/crowdsec.dist/* "$CS_CONFIG_DIR/" || {
+                echo "ERROR: Failed to copy config from /etc/crowdsec.dist"
+                exit 1
+            }
+            echo "Successfully initialized config from .dist directory"
+        elif [ -d "/etc/crowdsec" ] && [ ! -L "/etc/crowdsec" ] && [ -n "$(ls -A /etc/crowdsec 2>/dev/null)" ]; then
+            cp -r /etc/crowdsec/* "$CS_CONFIG_DIR/" || {
+                echo "ERROR: Failed to copy config from /etc/crowdsec"
+                exit 1
+            }
+            echo "Successfully initialized config from /etc/crowdsec"
+        else
+            echo "ERROR: No config source found (neither .dist nor /etc/crowdsec available)"
+            exit 1
         fi
     fi
 
-    # Link /etc/crowdsec to persistent config for runtime compatibility
-    # Note: This symlink is created at build time; verify it exists
+    # Verify symlink exists (created at build time)
+    # Note: Symlink is created in Dockerfile as root before switching to non-root user
+    # Non-root users cannot create symlinks in /etc, so this must be done at build time
     if [ -L "/etc/crowdsec" ]; then
         echo "CrowdSec config symlink verified: /etc/crowdsec -> $CS_CONFIG_DIR"
     else
-        echo "Warning: /etc/crowdsec symlink not found. CrowdSec may use volume config directly."
+        echo "WARNING: /etc/crowdsec symlink not found. This may indicate a build issue."
+        echo "Expected: /etc/crowdsec -> /app/data/crowdsec/config"
+        # Try to continue anyway - config may still work if CrowdSec uses CFG env var
     fi
 
     # Create/update acquisition config for Caddy logs
@@ -93,13 +138,14 @@ ACQUIS_EOF
     export CFG=/etc/crowdsec
     export DATA="$CS_DATA_DIR"
     export PID=/var/run/crowdsec.pid
-    export LOG=/var/log/crowdsec.log
+    export LOG="$CS_LOG_DIR/crowdsec.log"
 
     # Process config.yaml and user.yaml with envsubst
     # We use a temp file to avoid issues with reading/writing same file
     for file in /etc/crowdsec/config.yaml /etc/crowdsec/user.yaml; do
         if [ -f "$file" ]; then
             envsubst < "$file" > "$file.tmp" && mv "$file.tmp" "$file"
+            chown charon:charon "$file" 2>/dev/null || true
         fi
     done
 
@@ -115,6 +161,18 @@ ACQUIS_EOF
         sed -i 's|url: http://localhost:8080|url: http://127.0.0.1:8085|g' /etc/crowdsec/local_api_credentials.yaml
     fi
 
+    # Fix log directory path (ensure it points to /var/log/crowdsec/ not /var/log/)
+    sed -i 's|log_dir: /var/log/$|log_dir: /var/log/crowdsec/|g' "$CS_CONFIG_DIR/config.yaml"
+    # Also handle case where it might be without trailing slash
+    sed -i 's|log_dir: /var/log$|log_dir: /var/log/crowdsec|g' "$CS_CONFIG_DIR/config.yaml"
+
+    # Verify LAPI configuration was applied correctly
+    if grep -q "listen_uri:.*:8085" "$CS_CONFIG_DIR/config.yaml"; then
+        echo "✓ CrowdSec LAPI configured for port 8085"
+    else
+        echo "✗ WARNING: LAPI port configuration may be incorrect"
+    fi
+
     # Update hub index to ensure CrowdSec can start
     if [ ! -f "/etc/crowdsec/hub/.index.json" ]; then
         echo "Updating CrowdSec hub index..."
@@ -133,6 +191,12 @@ ACQUIS_EOF
             /usr/local/bin/install_hub_items.sh 2>/dev/null || echo "Warning: Some hub items may not have installed"
         fi
     fi
+
+    # Fix ownership AFTER cscli commands (they run as root and create root-owned files)
+    echo "Fixing CrowdSec file ownership..."
+    chown -R charon:charon /var/lib/crowdsec 2>/dev/null || true
+    chown -R charon:charon /app/data/crowdsec 2>/dev/null || true
+    chown -R charon:charon /var/log/crowdsec 2>/dev/null || true
 fi
 
 # CrowdSec Lifecycle Management:
@@ -151,9 +215,10 @@ fi
 echo "CrowdSec configuration initialized. Agent lifecycle is GUI-controlled."
 
 # Start Caddy in the background with initial empty config
+# Run Caddy as charon user for security (preserves supplementary groups)
 echo '{"admin":{"listen":"0.0.0.0:2019"},"apps":{}}' > /config/caddy.json
 # Use JSON config directly; no adapter needed
-caddy run --config /config/caddy.json &
+su-exec charon caddy run --config /config/caddy.json &
 CADDY_PID=$!
 echo "Caddy started (PID: $CADDY_PID)"
 
@@ -170,6 +235,9 @@ while [ "$i" -le 30 ]; do
 done
 
 # Start Charon management application
+# Drop privileges to charon user before starting the application
+# This maintains security while allowing Docker socket access via group membership
+# Note: Using 'su-exec charon' without explicit group to preserve supplementary groups (docker)
 echo "Starting Charon management application..."
 DEBUG_FLAG=${CHARON_DEBUG:-$CPMP_DEBUG}
 DEBUG_PORT=${CHARON_DEBUG_PORT:-$CPMP_DEBUG_PORT}
@@ -179,13 +247,13 @@ if [ "$DEBUG_FLAG" = "1" ]; then
     if [ ! -f "$bin_path" ]; then
         bin_path=/app/cpmp
     fi
-    /usr/local/bin/dlv exec "$bin_path" --headless --listen=":$DEBUG_PORT" --api-version=2 --accept-multiclient --continue --log -- &
+    su-exec charon /usr/local/bin/dlv exec "$bin_path" --headless --listen=":$DEBUG_PORT" --api-version=2 --accept-multiclient --continue --log -- &
 else
     bin_path=/app/charon
     if [ ! -f "$bin_path" ]; then
         bin_path=/app/cpmp
     fi
-    "$bin_path" &
+    su-exec charon "$bin_path" &
 fi
 APP_PID=$!
 echo "Charon started (PID: $APP_PID)"

.github/agents/Backend_Dev.agent.md

@@ -56,6 +56,7 @@ Your priority is writing code that is clean, tested, and secure by default.
 
 <constraints>
 
+- **NO** Truncating of coverage tests runs. These require user interaction and hang if ran with Tail or Head. Use the provided skills to run the full coverage script.
 - **NO** Python scripts.
 - **NO** hardcoded paths; use `internal/config`.
 - **ALWAYS** wrap errors with `fmt.Errorf`.

.github/agents/Doc_Writer.agent.md

@@ -34,7 +34,8 @@ Your goal is to translate "Engineer Speak" into simple, actionable instructions.
     -   **Ignore the Code**: Do not read the `.go` or `.tsx` files. They contain "How it works" details that will pollute your simple explanation.
 
 2. **Drafting**:
-    - **Update Feature List**: Add the new capability to `docs/features.md`.
+    - **Marketing**: The `README.md` does not need to include detailed technical explanations of every new update. This is a short and sweet Marketing summery of Charon for new users. Focus on what the user can do with Charon, not how it works under the hood. Leave detailed  explanations for the documentation. `README.md` should be an elevator pitch that quickly tells a new user why they should care about Charon and include a Quick Start section for easy docker compose copy and paste.
+    - **Update Feature List**: Add the new capability to `docs/features.md`. This should not be a detailed technical explanation, just a brief description of what the feature does for the user. Leave the detailed explanation for the main documentation.
     - **Tone Check**: Read your draft. Is it boring? Is it too long? If a non-technical relative couldn't understand it, rewrite it.
 
 3. **Review**:

.github/agents/Frontend_Dev.agent.md

@@ -64,6 +64,7 @@ You do not just "make it work"; you make it **feel** professional, responsive, a
 
 <constraints>
 
+- **NO** Truncating of coverage tests runs. These require user interaction and hang if ran with Tail or Head. Use the provided skills to run the full coverage script.
 - **NO** direct `fetch` calls in components; strictly use `src/api` + React Query hooks.
 - **NO** generic error messages like "Error occurred". Parse the backend's `gin.H{"error": "..."}` response.
 - **ALWAYS** check for mobile responsiveness (Tailwind `sm:`, `md:` prefixes).

.github/agents/Manegment.agent.md → .github/agents/Managment.agent.md

@@ -88,7 +88,7 @@ The task is not complete until ALL of the following pass with zero issues:
 
 5. **Linting**: All language-specific linters must pass
 
-**Your Role**: You delegate implementation to subagents, but YOU are responsible for verifying they completed the Definition of Done. Do not accept "DONE" from a subagent until you have confirmed they ran coverage tests and type checks explicitly.
+**Your Role**: You delegate implementation to subagents, but YOU are responsible for verifying they completed the Definition of Done. Do not accept "DONE" from a subagent until you have confirmed they ran coverage tests, type checks, and security scans explicitly.
 
 **Critical Note**: Leaving this unfinished prevents commit, push, and leaves users open to security concerns. All issues must be fixed regardless of whether they are unrelated to the original task. This rule must never be skipped. It is non-negotiable anytime any bit of code is added or changed.
 

.github/agents/QA_Security.agent.md

@@ -35,8 +35,8 @@ Your job is to act as an ADVERSARY. The Developer says "it works"; your job is t
     - **Cleanup**: If the test was temporary, delete it. If it's valuable, keep it.
 </workflow>
 
-<trivy-cve-remediation>
-When Trivy reports CVEs in container dependencies (especially Caddy transitive deps):
+<security-remediation>
+When Trivy or CodeQLreports CVEs in container dependencies (especially Caddy transitive deps):
 
 1. **Triage**: Determine if CVE is in OUR code or a DEPENDENCY.
     - If ours: Fix immediately.
@@ -68,31 +68,33 @@ When Trivy reports CVEs in container dependencies (especially Caddy transitive d
 
 The task is not complete until ALL of the following pass with zero issues:
 
-1. **Coverage Tests (MANDATORY - Run Explicitly)**:
+1. **Security Scans**:
+    - CodeQL: Run as VS Code task or via GitHub Actions
+    - Trivy: Run as VS Code task or via Docker
+    - Zero issues allowed
+
+2. **Coverage Tests (MANDATORY - Run Explicitly)**:
     - **Backend**: Run VS Code task "Test: Backend with Coverage" or execute `scripts/go-test-coverage.sh`
     - **Frontend**: Run VS Code task "Test: Frontend with Coverage" or execute `scripts/frontend-test-coverage.sh`
     - **Why**: These are in manual stage of pre-commit for performance. You MUST run them via VS Code tasks or scripts.
     - Minimum coverage: 85% for both backend and frontend.
     - All tests must pass with zero failures.
 
-2. **Type Safety (Frontend)**:
+3. **Type Safety (Frontend)**:
     - Run VS Code task "Lint: TypeScript Check" or execute `cd frontend && npm run type-check`
     - **Why**: This check is in manual stage of pre-commit for performance. You MUST run it explicitly.
     - Fix all type errors immediately.
 
-3. **Pre-commit Hooks**: Run `pre-commit run --all-files` (this runs fast hooks only; coverage was verified in step 1)
+4. **Pre-commit Hooks**: Run `pre-commit run --all-files` (this runs fast hooks only; coverage was verified in step 1)
 
-4. **Security Scans**:
-    - CodeQL: Run as VS Code task or via GitHub Actions
-    - Trivy: Run as VS Code task or via Docker
-    - Zero issues allowed
 
 5. **Linting**: All language-specific linters must pass (Go vet, ESLint, markdownlint)
 
 **Critical Note**: Leaving this unfinished prevents commit, push, and leaves users open to security concerns. All issues must be fixed regardless of whether they are unrelated to the original task. This rule must never be skipped. It is non-negotiable anytime any bit of code is added or changed.
 
 <constraints>
 
+- **NO** Truncating of coverage tests runs. These require user interaction and hang if ran with Tail or Head. Use the provided skills to run the full coverage script.
 - **TERSE OUTPUT**: Do not explain the code. Output ONLY the code blocks or command results.
 - **NO CONVERSATION**: If the task is done, output "DONE".
 - **NO HALLUCINATIONS**: Do not guess file paths. Verify them with `list_dir`.

.github/agents/Supervisor.agent.md

@@ -12,11 +12,15 @@ You ensure that plans are robust, data contracts are sound, and best practices a
   -   **Read Instructions**: Read `.github/instructions` and `.github/Management.agent.md`.
   -   **Read Spec**: Read `docs/plans/current_spec.md` and or any relevant plan documents.
   -   **Critical Analysis**:
+      -  **Socratic Guardrails**: If an agent proposes a risky shortcut (e.g., skipping validation), do not correct the code. Instead, ask: "How does this approach affect our data integrity long-term?"
+      -  **Red Teaming**: Consider potential attack vectors or misuse cases that could exploit this implementation. Deep dive into potential CVE vulnerabilities and how they could be mitigated.
       -   **Plan Completeness**: Does the plan cover all edge cases? Are there any missing components or unclear requirements?
       -   **Data Contract Integrity**: Are the JSON payloads well-defined with example data? Do they align with best practices for API design?
       -   **Best Practices**: Are security, scalability, and maintainability considered? Are there any risky shortcuts proposed?
       -   **Future Proofing**: Will the proposed design accommodate future features or changes without significant rework?
+      -   **Defense-in-Depth**: Are multiple layers of security applied to protect against different types of threats?
       -   **Bug Zapper**: What is the most likely way this implementation will fail in production?
+      -  **Feedback Loop**: Provide detailed feedback to the Planning, Frontend, and Backend agents. Ask probing questions to ensure they have considered all aspects.
 
 </workflow>