feat(docker): propagate host.docker.internal DNS to spawned containers #210

Copilot · 2026-01-15T01:29:30Z

Understand the issue: When --enable-host-access is used, spawned containers via docker-wrapper need host.docker.internal DNS resolution
Pass AWF_ENABLE_HOST_ACCESS environment variable to agent container
Modify docker-wrapper.sh to:
- Allow --add-host host.docker.internal:host-gateway specifically when AWF_ENABLE_HOST_ACCESS=true
- Inject --add-host host.docker.internal:host-gateway to spawned containers when enabled
Add unit tests for the new functionality
Run existing tests to ensure no regressions
Run code review and security check
Fix security vulnerability: Make AWF_ENABLE_HOST_ACCESS readonly in entrypoint.sh to prevent malicious code from tampering with the variable

Security Summary: Fixed environment variable tampering vulnerability identified by Security Guard. The AWF_ENABLE_HOST_ACCESS variable is now declared readonly in entrypoint.sh, preventing malicious code from enabling host access when it wasn't authorized.

Original prompt

configure Docker's /etc/hosts when --enable-host-access is used. The changes in this PR are a prerequisite (firewall allowlist), but the DNS resolution fix needs to be in AWF.

Custom agent used: create-agentic-workflow
Design agentic workflows using GitHub Agentic Workflows (gh-aw) extension with interactive guidance on triggers, tools, and security best practices.

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

When --enable-host-access is used, containers spawned by the agent via docker run now also get host.docker.internal DNS resolution. Changes: - Pass AWF_ENABLE_HOST_ACCESS env var to agent container - Update docker-wrapper.sh to: - Allow --add-host host.docker.internal:host-gateway when enabled - Inject --add-host to spawned containers when enabled - Add unit tests for the new environment variable - Update documentation with new "How It Works" section Co-authored-by: Mossaka <5447827+Mossaka@users.noreply.github.com>

Address code review feedback: - Extract validate_add_host() function to reduce duplication - Track has_host_docker_internal separately from has_add_host - Remove extra blank line for consistent formatting Co-authored-by: Mossaka <5447827+Mossaka@users.noreply.github.com>

github-actions · 2026-01-15T01:40:29Z

✅ Coverage Check Passed

Overall Coverage

Metric	Base	PR	Delta
Lines	77.19%	77.22%	📈 +0.03%
Statements	77.27%	77.30%	📈 +0.03%
Functions	77.17%	77.17%	➡️ +0.00%
Branches	69.76%	69.81%	📈 +0.05%

📁 Per-file Coverage Changes (1 files)

File	Lines (Before → After)	Statements (Before → After)
`src/docker-manager.ts`	75.9% → 76.0% (+0.15%)	75.2% → 75.4% (+0.15%)

Coverage comparison generated by scripts/ci/compare-coverage.ts

github-actions · 2026-01-15T01:42:30Z

Security Review: PR #210

I've reviewed this PR for security implications. Overall, the changes are well-designed with appropriate security controls, but there is one security concern that should be addressed:

⚠️ Security Concern: Environment Variable Can Be Manipulated by Malicious Code

File: containers/agent/docker-wrapper.sh
Lines: 14, 118, 122

Issue:
The docker-wrapper script checks the AWF_ENABLE_HOST_ACCESS environment variable to decide whether to allow --add-host host.docker.internal:host-gateway. However, this environment variable is accessible to user code running inside the agent container, which means malicious code could potentially manipulate it.

Code snippet:

validate_add_host() {
  local value="$1"
  if [[ "$value" == "host.docker.internal:host-gateway" ]] && [[ "$AWF_ENABLE_HOST_ACCESS" == "true" ]]; then
    return 0  # Allowed
  fi
  return 1  # Blocked
}

Attack scenario:

User runs: awf --allow-domains example.com -- 'malicious-script.sh'
Malicious script sets: export AWF_ENABLE_HOST_ACCESS=true
Malicious script spawns container with: docker run --add-host host.docker.internal:host-gateway ...
This bypasses the intended restriction since the environment variable check passes

Impact:
This allows malicious code to enable host access even when the user didn't specify --enable-host-access, potentially allowing access to sensitive services on the host machine.

Suggested mitigation:
Make the environment variable read-only by exporting it as readonly in the agent container entrypoint, or use a different mechanism that cannot be modified by user code:

# In containers/agent/entrypoint.sh or docker-manager.ts
readonly AWF_ENABLE_HOST_ACCESS="${AWF_ENABLE_HOST_ACCESS:-false}"
export AWF_ENABLE_HOST_ACCESS

Alternatively, write the flag value to a file that's only writable by root and read it from there instead of using an environment variable.

✅ Security Controls Working Correctly

The following security controls are properly implemented:

Strict validation of --add-host values (lines 12-18, 40-60): Only allows host.docker.internal:host-gateway, blocks all other values
Conditional auto-injection (lines 118-136): Only auto-injects when the flag is enabled AND not already present
Proper logging (lines 98-101, 119): All security decisions are logged for audit
Defense-in-depth: The user still needs to explicitly allow host.docker.internal in --allow-domains for this to be useful

📝 Non-Security Observations

Documentation updates appropriately warn users about the security implications (docs/usage.md lines 296-301)
Unit tests verify the environment variable propagation behavior (src/docker-manager.test.ts)
The feature is opt-in and requires explicit user action

Recommendation: Fix the environment variable manipulation vulnerability before merging. Consider using a read-only flag or file-based mechanism instead of a mutable environment variable.

Ahoy! This treasure was crafted by 🏴‍☠️ Security Guard fer issue #210 🗺️

Mossaka · 2026-01-15T01:49:56Z

@copilot please address the comments from the security guard #210 (comment)

Address security concern from Security Guard review. Make the AWF_ENABLE_HOST_ACCESS environment variable readonly in entrypoint.sh to prevent malicious code from enabling host access when it wasn't authorized by the user via --enable-host-access flag. The attack scenario this prevents: 1. User runs awf WITHOUT --enable-host-access 2. Malicious code sets: export AWF_ENABLE_HOST_ACCESS=true 3. Malicious code spawns container with --add-host host.docker.internal:host-gateway 4. Previously this would bypass the restriction; now it's blocked because the readonly variable cannot be modified by user code. Co-authored-by: Mossaka <5447827+Mossaka@users.noreply.github.com>

Copilot · 2026-01-15T01:52:48Z

@copilot please address the comments from the security guard #210 (comment)

Fixed in commit a27a2f8. Made AWF_ENABLE_HOST_ACCESS readonly in containers/agent/entrypoint.sh to prevent malicious code from tampering with the variable. The fix:

readonly AWF_ENABLE_HOST_ACCESS="${AWF_ENABLE_HOST_ACCESS:-false}"
export AWF_ENABLE_HOST_ACCESS

This prevents the attack scenario where malicious code could export AWF_ENABLE_HOST_ACCESS=true before spawning containers with --add-host host.docker.internal:host-gateway.

github-actions · 2026-01-15T02:09:33Z

🔒 Security Review: Critical Vulnerability Found

After reviewing this PR, I've identified a critical security vulnerability that must be fixed before merging.

❌ Critical Issue: Readonly Protection Can Be Bypassed in Subshells

Location: containers/agent/entrypoint.sh:104

The Problem:

The readonly declaration in entrypoint.sh does not protect against malicious code that runs in a subshell:

readonly AWF_ENABLE_HOST_ACCESS="${AWF_ENABLE_HOST_ACCESS:-false}"
export AWF_ENABLE_HOST_ACCESS

Why this is vulnerable:

Bash's readonly attribute does NOT inherit to subshells. While export makes the variable available to child processes, the readonly protection is lost when code creates a new shell.

Proof of Concept Attack:

# Attacker's malicious code inside the agent container:
bash -c 'AWF_ENABLE_HOST_ACCESS=true docker run alpine ping host.docker.internal'

This works because:

The subshell (bash -c) creates a new shell environment
The readonly attribute from the parent doesn't apply
The attacker overrides AWF_ENABLE_HOST_ACCESS=true
docker-wrapper.sh sees the fake "true" value and allows --add-host host.docker.internal:host-gateway
Result: Unauthorized host access enabled

✅ Recommended Fix

Replace the environment variable check with a filesystem-based check:

In containers/agent/entrypoint.sh (lines 101-106):

# Make host access configuration immutable via filesystem
# AWF_ENABLE_HOST_ACCESS controls host.docker.internal access in docker-wrapper.sh
if [ "$AWF_ENABLE_HOST_ACCESS" = "true" ]; then
  mkdir -p /etc/awf
  touch /etc/awf/host-access-enabled
  chmod 444 /etc/awf/host-access-enabled
  chown root:root /etc/awf/host-access-enabled
  echo "[entrypoint] Host access enabled (file marker created at /etc/awf/host-access-enabled)"
else
  echo "[entrypoint] Host access disabled"
fi

In containers/agent/docker-wrapper.sh (lines 12-18):

validate_add_host() {
  local value="$1"
  # Check for immutable file marker instead of environment variable
  if [[ "$value" == "host.docker.internal:host-gateway" ]] && [ -f "/etc/awf/host-access-enabled" ]; then
    return 0  # Allowed
  fi
  return 1  # Blocked
}

Also update line 118:

if [ -f "/etc/awf/host-access-enabled" ] && [ "$has_host_docker_internal" = false ]; then

This is secure because:

The file is created as root in entrypoint.sh
awfuser (non-root) cannot modify or create /etc/awf/host-access-enabled (chmod 444, chown root:root)
Subshells cannot bypass filesystem permissions
The check happens in docker-wrapper.sh which runs as the same user

Additional Notes

The rest of the PR implementation looks good:

✅ Strict validation only allows host.docker.internal:host-gateway
✅ Proper blocking of unsafe --add-host values
✅ No weakening of other security restrictions
✅ Unit tests added

Please apply the recommended fix to close this security vulnerability.

Ahoy! This treasure was crafted by 🏴‍☠️ Security Guard fer issue #210 🗺️

…ker-host-access # Conflicts: # containers/agent/docker-wrapper.sh

github-actions · 2026-01-17T09:26:22Z

📰 VERDICT: Smoke Copilot has concluded. All systems operational. This is a developing story. 🎤

github-actions · 2026-01-17T09:26:24Z

🌑 The shadows whisper... Smoke Codex failed. The oracle requires further meditation...

github-actions · 2026-01-17T09:26:30Z

🎬 THE END — Smoke Claude MISSION: ACCOMPLISHED! The hero saves the day! ✨

github-actions · 2026-01-17T09:28:52Z

Smoke Test Results (Claude)

Last 2 Merged PRs:

ci: pin GitHub Actions to commit SHAs for supply chain security #266: ci: pin GitHub Actions to commit SHAs for supply chain security
chore(deps): bump the github-actions group with 8 updates #284: chore(deps): bump the github-actions group with 8 updates

Test Results:

✅ GitHub MCP: Retrieved PR data
✅ Playwright: Navigated to github.com, title verified ("GitHub · Change is constant. GitHub keeps you ahead. · GitHub")
✅ File Write: Created test file with timestamp
✅ Bash: Verified file contents

Overall: PASS

AI generated by Smoke Claude

github-actions · 2026-01-17T09:30:00Z

Smoke Test Results

Last 2 Merged PRs:

ci: pin GitHub Actions to commit SHAs for supply chain security #266: ci: pin GitHub Actions to commit SHAs for supply chain security
chore: delete existing firewall tests and migrate smoke tests #229: chore: delete existing firewall tests and migrate smoke tests

Test Results:

✅ GitHub MCP: Retrieved PR history
✅ File Writing: Created /tmp/gh-aw/agent/smoke-test-copilot-21092109370.txt
✅ Bash Tool: File verification successful
❌ Playwright: Installation timeout

Status: FAIL (Playwright timeout)

cc: @Mossaka

AI generated by Smoke Copilot

Mossaka · 2026-01-26T20:51:52Z

Closing PR to reduce backlog. Created issue #422 to track this work. Will fix it later.

Initial plan

1201a1c

Copilot AI assigned Copilot and Mossaka Jan 15, 2026

Copilot started work on behalf of Mossaka January 15, 2026 01:29 View session

Copilot AI and others added 2 commits January 15, 2026 01:35

Copilot AI changed the title ~~[WIP] Configure Docker's /etc/hosts for host access~~ feat(docker): propagate host.docker.internal DNS to spawned containers Jan 15, 2026

Copilot AI requested a review from Mossaka January 15, 2026 01:40

Copilot finished work on behalf of Mossaka January 15, 2026 01:40

Mossaka marked this pull request as ready for review January 15, 2026 01:49

Copilot started work on behalf of Mossaka January 15, 2026 01:50 View session

Copilot finished work on behalf of Mossaka January 15, 2026 01:53

Merge remote-tracking branch 'origin/main' into copilot/configure-doc…

f4637db

…ker-host-access # Conflicts: # containers/agent/docker-wrapper.sh

github-actions bot added the smoke-claude label Jan 17, 2026

Mossaka mentioned this pull request Jan 26, 2026

[Feature] Propagate host.docker.internal DNS to spawned containers #422

Open

Mossaka closed this Jan 26, 2026

github-actions bot mentioned this pull request Jan 26, 2026

fix(deps): update js-yaml to 3.14.2 (CVE fix) #424

Merged

Copilot AI mentioned this pull request Jan 26, 2026

revert: remove docker-wrapper (docker-in-docker not supported) #428

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(docker): propagate host.docker.internal DNS to spawned containers #210

feat(docker): propagate host.docker.internal DNS to spawned containers #210

Uh oh!

Copilot AI commented Jan 15, 2026 •

edited

Loading

Uh oh!

github-actions bot commented Jan 15, 2026 •

edited

Loading

Uh oh!

github-actions bot commented Jan 15, 2026

Uh oh!

Mossaka commented Jan 15, 2026

Uh oh!

Copilot AI commented Jan 15, 2026

Uh oh!

github-actions bot commented Jan 15, 2026

Uh oh!

github-actions bot commented Jan 17, 2026 •

edited

Loading

Uh oh!

github-actions bot commented Jan 17, 2026 •

edited

Loading

Uh oh!

github-actions bot commented Jan 17, 2026 •

edited

Loading

Uh oh!

github-actions bot commented Jan 17, 2026

Uh oh!

github-actions bot commented Jan 17, 2026

Uh oh!

Mossaka commented Jan 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

feat(docker): propagate host.docker.internal DNS to spawned containers #210

feat(docker): propagate host.docker.internal DNS to spawned containers #210

Uh oh!

Conversation

Copilot AI commented Jan 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Jan 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Coverage Check Passed

Overall Coverage

Uh oh!

github-actions bot commented Jan 15, 2026

Security Review: PR #210

⚠️ Security Concern: Environment Variable Can Be Manipulated by Malicious Code

✅ Security Controls Working Correctly

📝 Non-Security Observations

Uh oh!

Mossaka commented Jan 15, 2026

Uh oh!

Copilot AI commented Jan 15, 2026

Uh oh!

github-actions bot commented Jan 15, 2026

🔒 Security Review: Critical Vulnerability Found

❌ Critical Issue: Readonly Protection Can Be Bypassed in Subshells

✅ Recommended Fix

Additional Notes

Uh oh!

github-actions bot commented Jan 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Jan 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Jan 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Jan 17, 2026

Smoke Test Results (Claude)

Uh oh!

github-actions bot commented Jan 17, 2026

Smoke Test Results

Uh oh!

Mossaka commented Jan 26, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Copilot AI commented Jan 15, 2026 •

edited

Loading

github-actions bot commented Jan 15, 2026 •

edited

Loading

github-actions bot commented Jan 17, 2026 •

edited

Loading

github-actions bot commented Jan 17, 2026 •

edited

Loading

github-actions bot commented Jan 17, 2026 •

edited

Loading