test(security): prove the guest-loopback nftables rule on a provider_authority_host

Open
  • Is something wrong?
#3,581 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
35/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
linux, python
Domain
devops, security

Research direction

Read docs/operating/runbooks/image-lifecycle.md and ADR-0810, then provision a lab host with the provider_authority_host role and run an egress System with the documented nftables rule keyed to the authority account's QEMU uid. Record whether the rule blocks the guest connection to 10.0.2.2 and whether authority readiness and provision/teardown still work; redact host names and addresses. If service behavior changes, update the runbook and ADR-0810 with the result.

Written by the indexing model from the issue text.

Description

area:security effort:M priority:P3 risk:daytime-only status:ready type:test

Problem

The rule that rejects new loopback connections from QEMU's uid (table inet kdive_guest_loopback) is documented as tested on the local-libvirt lanes only. Whether it is safe on a remote authority host, where one account owns both the session libvirt daemon and the authority service, is unproven; the runbook tells operators not to assume it.

Evidence

  • docs/operating/runbooks/image-lifecycle.md:362-364: "An authority host ... is unproven because no lab host carries provider_authority_host. Do not assume the rule is safe on either."
  • docs/adr/0810-guest-egress-host-loopback-exposure-is-accepted-and-documented.md:191-194: "Remote authority: unproven ... whether the service has a loopback dependency was not checked, so the rule's effect there is unknown." Operator accepted the limit on 2026-11-04.
  • ADR-0810:145-147: the single account kdive-provider-authority was read from deploy/ansible/roles/provider_authority_host, not from a running host.

Expected

A recorded result on a host provisioned with the provider_authority_host role: whether the keyed rule (a) blocks a guest connection to 10.0.2.2:<host loopback port>, and (b) leaves the authority service, its readiness and its provision/teardown path working, given that QEMU and the service share one uid.

Proposed approach

Provision one lab host with the role, run an egress System, load the documented rule keyed to the authority account's QEMU uid, and record the outcomes. Expect (b) to fail if the service uses loopback; if so, record the refusal and amend the runbook sentence from "unproven" to "not usable here", with an ADR-0810 amendment. Host-level proof; no code change expected. Redact host names and addresses.

Provenance

Follow-up from campaign 4c2c8dc9e59d-7f9a87f5-2251-458a-bb30-04fbb2d4b05c. Source: ADR-0810 #3514 amendment (2026-11-04).

Dominant language
Python
Stars
0
Forks
0
Avg merge
9h 13m
Merged PRs (30d)
197

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from randomparity/kdive

All issues in randomparity/kdive

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.