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

On 7/27/26 23:45, Avinash Duduskar wrote:
> From: Avinash H. Duduskar <[email protected]>
> 
> [Cc Kyle, since this is about what the mac work would have to cover.]
> 

Hi,

Thanks, I appreciate it.

>> 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.
> 

I'd note that a priv_grant technically isn't forbidden from inspecting
curproc/curthread to make a decision and we have a little bit of precedent
for that today.  I'm not sure that necessarily makes it any more the right
shape, though- we probably don't want the kind of priv proliferation that
might be necessary to give you the kind of flexibility that pf users may
want.

> 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.
> 

One thing I didn't really look at is whether netlink parsers mutate the
message, or whether we could reasonably export these from pf so that a MAC
policy can also use them.  Ideally, you would probably end up parsing
messages that MAC policies may be interested in twice, unless the parser
attaches some state to the message and the second invocation just returns
that instead of actually re-parsing the message.  I've spent basically no
time looking at how any of the Netlink stuff actually works, though.

Thanks,

Kyle Evans