Re: netlink(4) fine grained access control
Kristof Provost <[email protected]> Tue, 07 Jul 2026 15:04:52 +0200
| Newsgroups | gmane.os.freebsd.architechture |
|---|---|
| Message-ID | <[email protected]> |
--=_MailMate_4BD0AD85-DC98-4D71-8338-7A9C15E081FB_=
Content-Type: text/plain; charset=UTF-8; format=flowed; markup=markdown
Content-Transfer-Encoding: 8bit
On 6 Jul 2026, at 20:04, Kyle Evans wrote:
> I cast level 6 necromancy.
>
*gurgle*
> On 9/15/25 10:45, Kristof Provost wrote:
>> I’ve recently had a user raise an interesting issue (see
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289234 )
>>
>> For background: pf is in the process of converting the
>> userspace<>kernelspace interface to netlink. This is mostly a great
>> improvement, but it does mean that only the root user (or, the user
>> with PRIV_NETINET_PF privilege) can get information out of pf.
>>
>> That matches the default behaviour of the /dev/pf interface, but
>> users can choose to allow other users or groups to access pf through
>> a simple chmod/chown on /dev/pf. There’s no obvious way to do the
>> same with netlink.
>> From a brief inspection of the code I don’t think that any such
>> mechanism exists. I don’t particularly want to invent anything
>> specific to pf either.
>>
>> My initial impulse was to introduce a PRIV_NETINET_PF_RO priv, and to
>> have users grant that to whatever account they’d normally allow
>> access to /dev/pf, but the ability to set individual privileges for
>> accounts seems to be a linux-ism (e.g.
>> https://man7.org/linux/man-pages/man8/setcap.8.html ) and not
>> something we can do.
>>
>> So, any ideas or suggestions?
>>
>
> genl on Linux doesn't seem to have a similar notion, beyond just not
> requiring privileges for some operations that just fetch statistics.
> Technically you could make the relevant operations unprivileged and
> EPERM them after checking appropriate ucred in the handler, but that's
> ugly.
>
> We're still in discussions about upstreaming a mac_bsdpriv that can
> grant arbitrary privileges,
I’ve not actually looked all that deeply into what Linux does, but
I’ve been assuming that they expect processes/users/containers to be
granted additional privileges/capabilities.
Hence my comments about setcap.
In any event I don’t want to invent a pf-specific mechanism, but at
the same time users do really seem to want to grant pf access to
processes/jails that don’t get it by default.
Up to and including letting old-style jails manage pf. I don’t
understand, but apparently some people like their feet well ventilated.
The current check is `if (cmd->cmd_priv != 0 && !nlp_has_priv(nlp,
cmd->cmd_priv)) {` in
https://cgit.freebsd.org/src/tree/sys/netlink/netlink_generic.c#n146
Hence my thinking that we want to be able to grant specific
processes/users/jails additional privileges. That code also runs through
the MAC hooks, so it seems plausible that mac_bsdpriv would be the
answer here.
> but I think it would also be useful to add a MAC hook into
> `genl_handle_message` to pass the family + command context out to MAC
> for evaluation. That would open up some room for a policy that can do
> much finer-grained access control with just a little more MAC magic.
>
Sure, I think I can see how that’d be useful. Would we integrate that
in the existing cmd_priv check so that we can express ‘deny this if we
don’t have this priv, but allow it if the MAC call says it’s
okay’?
Best regards,
Kristof
--=_MailMate_4BD0AD85-DC98-4D71-8338-7A9C15E081FB_=
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html>
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/xhtml; charset=3Dutf-8"=
>
</head>
<body><div style=3D"font-family: sans-serif;"><div class=3D"markdown" sty=
le=3D"white-space: normal;">
<p dir=3D"auto">On 6 Jul 2026, at 20:04, Kyle Evans wrote:</p>
<blockquote style=3D"margin: 0 0 5px; padding-left: 5px; border-left: 2px=
solid #136BCE; color: #136BCE;">
<p dir=3D"auto">I cast level 6 necromancy.</p>
</blockquote>
<p dir=3D"auto"><em>gurgle</em></p>
<blockquote style=3D"margin: 0 0 5px; padding-left: 5px; border-left: 2px=
solid #136BCE; color: #136BCE;">
<p dir=3D"auto">On 9/15/25 10:45, Kristof Provost wrote:</p>
<blockquote style=3D"margin: 0 0 5px; padding-left: 5px; border-left: 2px=
solid #136BCE; border-left-color: #4B89CF; color: #4B89CF;">
<p dir=3D"auto">I=E2=80=99ve recently had a user raise an interesting iss=
ue (see <a href=3D"https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D28=
9234">https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D289234</a> )</p=
>
<p dir=3D"auto">For background: pf is in the process of converting the us=
erspace<>kernelspace interface to netlink. This is mostly a great i=
mprovement, but it does mean that only the root user (or, the user with P=
RIV_NETINET_PF privilege) can get information out of pf.</p>
<p dir=3D"auto">That matches the default behaviour of the /dev/pf interfa=
ce, but users can choose to allow other users or groups to access pf thro=
ugh a simple chmod/chown on /dev/pf. There=E2=80=99s no obvious way to do=
the same with netlink.<br>
=46rom a brief inspection of the code I don=E2=80=99t think that any such=
mechanism exists. I don=E2=80=99t particularly want to invent anything s=
pecific to pf either.</p>
<p dir=3D"auto">My initial impulse was to introduce a PRIV_NETINET_PF_RO =
priv, and to have users grant that to whatever account they=E2=80=99d nor=
mally allow access to /dev/pf, but the ability to set individual privileg=
es for accounts seems to be a linux-ism (e.g. <a href=3D"https://man7.org=
/linux/man-pages/man8/setcap.8.html">https://man7.org/linux/man-pages/man=
8/setcap.8.html</a> ) and not something we can do.</p>
<p dir=3D"auto">So, any ideas or suggestions?</p>
</blockquote>
<p dir=3D"auto">genl on Linux doesn't seem to have a similar notion, beyo=
nd just not requiring privileges for some operations that just fetch stat=
istics. Technically you could make the relevant operations unprivileged =
and EPERM them after checking appropriate ucred in the handler, but that'=
s ugly.</p>
<p dir=3D"auto">We're still in discussions about upstreaming a mac_bsdpri=
v that can grant arbitrary privileges,</p>
</blockquote>
<p dir=3D"auto">I=E2=80=99ve not actually looked all that deeply into wha=
t Linux does, but I=E2=80=99ve been assuming that they expect processes/u=
sers/containers to be granted additional privileges/capabilities.<br>
Hence my comments about setcap.</p>
<p dir=3D"auto">In any event I don=E2=80=99t want to invent a pf-specific=
mechanism, but at the same time users do really seem to want to grant pf=
access to processes/jails that don=E2=80=99t get it by default.<br>
Up to and including letting old-style jails manage pf. I don=E2=80=99t un=
derstand, but apparently some people like their feet well ventilated.</p>=
<p dir=3D"auto">The current check is <code style=3D"padding: 0 0.25em; ba=
ckground-color: #E4E4E4;">if (cmd->cmd_priv !=3D 0 && !nlp_has=
_priv(nlp, cmd->cmd_priv)) {</code> in <a href=3D"https://cgit.freebsd=
=2Eorg/src/tree/sys/netlink/netlink_generic.c#n146">https://cgit.freebsd.=
org/src/tree/sys/netlink/netlink_generic.c#n146</a><br>
Hence my thinking that we want to be able to grant specific processes/use=
rs/jails additional privileges. That code also runs through the MAC hooks=
, so it seems plausible that mac_bsdpriv would be the answer here.</p>
<blockquote style=3D"margin: 0 0 5px; padding-left: 5px; border-left: 2px=
solid #136BCE; color: #136BCE;">
<p dir=3D"auto">but I think it would also be useful to add a MAC hook int=
o <code style=3D"padding: 0 0.25em; background-color: #E4E4E4;">genl_hand=
le_message</code> to pass the family + command context out to MAC for eva=
luation. That would open up some room for a policy that can do much fine=
r-grained access control with just a little more MAC magic.</p>
</blockquote>
<p dir=3D"auto">Sure, I think I can see how that=E2=80=99d be useful. Wou=
ld we integrate that in the existing cmd_priv check so that we can expres=
s =E2=80=98deny this if we don=E2=80=99t have this priv, but allow it if =
the MAC call says it=E2=80=99s okay=E2=80=99?</p>
<p dir=3D"auto">Best regards,<br>
Kristof</p>
</div>
</div>
</body>
</html>
--=_MailMate_4BD0AD85-DC98-4D71-8338-7A9C15E081FB_=--