Skip to content

Hostless web egress conflicts with a pinned provider endpoint #4662

Open

Description

@rsliter

User Story

I use OpenShell through NemoClaw with a custom HTTPS inference provider. I need its exact IP pins and request restrictions alongside broad web access for a trusted personal sandbox.

Problem Statement

NemoClaw's Personal preset grants broad TCP egress on ports 80 and 443 to trusted personal sandboxes. OpenShell 0.1.3 rejects this hostless rule after HTTPS provider attachment when their allowed_ips lists differ (NemoClaw #13349).

OpenShell permits request-level overlaps when connection settings agree. This pair conflicts on allowed_ips.

For example, the provider pins example.com:443 to 172.66.147.243. The hostless Personal rule covers port 443 and includes 172.0.0.0/6, which contains that IP. The lists differ, so OpenShell rejects the update even though the pinned IP is within Personal's range.

Impact / Why This Matters

The agent loses Personal web access while the prior policy remains active. Matching the provider's list to Personal's would remove its exact pins.

Acceptance Criteria

  • A hostless web rule can coexist with a provider endpoint that retains its exact IP pins, REST restrictions, and credential binding.
  • Public web access works; provider requests outside its permitted IPs or paths and always-blocked destinations remain denied.
  • Invalid combinations still fail atomically with an actionable reason.

Reproduction Steps

  1. On OpenShell 0.1.3, create a sandbox and attach a REST provider for example.com:443 with allowed_ips: [172.66.147.243], a /v1/** selector, and a placeholder credential.
  2. Submit a policy with a hostless endpoint on ports 80 and 443 and allowed_ips: [172.0.0.0/6]: openshell policy set --policy <policy.yaml> <sandbox> --wait. NemoClaw's Personal preset contains that range.
  3. Observe network endpoint ambiguity validation failed on allowed_ips. The prior policy version and hash remain active. Native test details.

Environment

  • Native reproduction: OpenShell 0.1.3, macOS ARM64, Docker Desktop gateway and sandbox; disposable resources removed.
  • Latest release 0.1.4 has the same allowed_ips comparison. We have not rerun the native reproduction on 0.1.4.

Potential solutions for consideration

  1. Combine address restrictions: Require the resolved address to satisfy each matching allowed_ips list. Keep request and credential decisions separate.
    For example, example.com:443 at 172.66.147.243 passes both checks; another address in 172.0.0.0/6 fails the provider pin.

  2. Exclude provider hosts from the broad rule: Let the provider endpoint own its host while the hostless rule covers other hosts. This needs a defined exclusion mechanism and behavior when providers attach or detach.
    For example, example.com:443 uses only the provider rule, while news.example:443 uses Personal.

Which model fits OpenShell's rule composition? How should absent allowed_ips, different matching binaries, and L4 beside inspected REST rules behave? Are there other approaches we could consider?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    state:triage-neededOpened without agent diagnostics and needs triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions