netlink: allow netlink sockets in non-vnet jails.

[melifaro]

Summary

Netlink overview

Processes communicate with netlink via sockets to either a) get information from the kernel, b) change some state in the kernel and c) receive the notifications of the changed state in the kernel.

Currently, Netlink provides the functionality via the following command families:

Family NETLINK_ROUTE:

• add/del/update route/nexhops/interface/address/arp/ndp records
• receive updates on the changes of the objects above

Family NETLINK_GENERIC

Sub-family CARP:

• get/set carp interface attributes.

Change description

This change allow to open Netlink sockets in the non-vnet jails, even for unpriviledged processes.
The security model largely follows the existing one. To be more specific:

• by default, every NETLINK_ROUTE command is NOT allowed in non-VNET jail UNLESS RTNL_F_ALLOW_NONVNET_JAIL flag is specified in the command handler
• All notifications are disabled for non-vnet jails (requests to subscribe for the notifications are ignored). This will change to be more fine-grained model once the first netlink provider requiring this gets committed.
• Listing interfaces (RTM_GETLINK) is allowed w/o limits (including interfaces w/o any addresses attached to the jail). The value of this is questionable, but it follows the existing approach
• Listing ARP/NDP neighbours is forbidden. This is a change from the current approach - currently we list static ARP/ND entries belonging to the addresses attached to the jail.
• Listing interface addresses is allowed, but the addresses are filtered to match only ones attached to the jail.
• Listing routes is allowed, but the routes are filtered to provide only host routes matching the addresses attached to the jail.
• By default, every NETLINK_GENERIC command is allowed in non-VNET jail (as sub-families may be unrelated to network at all). It is the goal of family author to implement the restrictions
• All current CARP commands (CARP_NL_CMD_GET, CARP_NL_CMD_SET) are forbidden to run in non-VNET jails.

[kp]

sys/netinet/ip_carp.c

2341 ↗

(On Diff #119249)

We do already check for PRIV_NETINET_CARP (on the set call), so I'm not clear on why we also need this check. (prison_priv_check() should mean regular jails never get this privilege.)

It also changes behaviour, in that with the old-style ioctl we can retrieve carp configuration without any restrictions (other than not returning the password), but we won't be able to with netlink.

[melifaro]

sys/netinet/ip_carp.c

2341 ↗

(On Diff #119249)

Ack.

Re SET call - for some reason, I forgot that the priv_check() actually goes through prison_priv_check() so this should be unnecessary. Thank you for pointing this out, I'll update the diff.

Re GET call - I'll remove the check as well. I'm a bit curious if there are any reasons (other than compat) on why do we want to export CARP-specific config to the jail which only allowed to know about the IP addresses. I don't have a strong opinion here, it's more about "if we're redoing it, maybe it's worth re-checking if the implemented security policy is the desired policy".

[kp]

sys/netinet/ip_carp.c

2341 ↗

(On Diff #119249)

I'm not sure why it currently works the way it does. I don't have any particular insight there.

It's kind of hard to justify hiding it in netlink while the old ioctl is still around providing that information. On the other hand, if we want to hide it later now is a good time to change it, even with that caveat. (After all, the old ioctl will go away sooner or later.)

On the third hand, users get up to all sorts of crazy things, and it's not at all impossible that one will turn up to complain that we broke his 'carp on the host, jail monitoring the carp status' setup. https://xkcd.com/1172/