Re: PR 291981: authpf under netlink, and a pfctl adoption flag

From: Avinash H. Duduskar <[email protected]>

[Cc Kyle, since this is about what the mac work would have to cover.]

> Groan. I didn't realise authpf changed rules. I had assumed it only
> added/deleted addresses in tables.

Right, and a step further than that: what it loads is pf.conf syntax,
parsed by parse.y.  Which is also why you ran into

> those files might include other files

when you looked at capsicum.  That is parse.y's include, and it nests,
so the file set is open-ended by design rather than by accident.

That is also why I do not think the mac module lands on this one, and I
would rather say so now than after 291981 has waited for it.

Reading the arch thread again, the problem being solved there is the
chmod /dev/pf replacement: give a known account or jail access to pf,
configured once, and originally read-only.  For that, granting by
identity is exactly right, and Kyle's "meets most needs" is fair:
https://lists.freebsd.org/archives/freebsd-arch/2026-July/001359.html

authpf is a different beast in every form.  The account is whoever logs
in rather than one you configured, the grant has to last exactly one
session, the access is write, and what gets written is mediated: a
root-owned rules file into authpf/<user>(<pid>), with the macros filled
in from the session and not from the user.

mac_priv_grant() is handed a credential and a privilege number, so
whatever a policy grants, it grants to an identity, ambiently.  Give the
login user PRIV_NETINET_PF and they have pf from any process at any
time, not only inside the session authpf is mediating: they can load
their own ruleset, or flush yours.  The pid is in the anchor name, so a
policy cannot narrow it to the session's target either.

There is the config surface too.  On 14.x making someone an authpf user
is one step, set their shell.  Granting by identity means naming every
authpf user in policy and keeping that current as they come and go,
which kills authpf's zero-config property.

The table-scoped policy Kyle sketched would cover the table half, which
I think is the half you had in mind.  The ruleset load is the other one.

A per-session label set before the exec is the only shape I can think of
that would fit, but I have not seen anyone propose it, and that is
authpf handing out a capability again rather than the mac module
landing.

None of this is me pushing the flag again, and where it goes is your
call.  I just want the next person taking a shot at this to be
clear-eyed about authpf's actual internals and the total effort of the
fix.

Best,
Avinash