On Wed, 9 Jul 2025, Doug Rabson wrote:
Hi Doug,
On Wed, 9 Jul 2025 at 13:12, Alexander Leidinger <[email protected]>
wrote:
Am 2025-07-09 12:20, schrieb Doug Rabson:
I would like to be able to create and modify network interfaces inside
jails. Use cases for this include supporting nesting Podman jails and CNI
plugins which delegate some of their functionality into a helper jail.
Nesting Podman jails nearly works already using the existing jail nesting
support but right now, it cannot manage networking configuration for its
container jails since creating and modifying bridge instances is not
permitted. CNI plugins with associated helper utilities are very common in
Linux and it is often helpful to distribute these as container images which
run with sufficient privileges to manage the network state - this
management often includes creating and manipulating network interfaces.
As far as I can tell, creating new interfaces in jails is gated by the
PRIV_NET_IFCREATE privilege and adding/removing interfaces to a bridge is
gated by PRIV_NET_BRIDGE. Unfortunately, I can't see a way to enable either
privilege in a jail - there are no corresponding "allow.foo" parameters for
these privileges.
Any ideas on how to approach this? I could easily add calls to
prison_add_allow in the kernel but I wanted to understand why they don't
already exist. Is there some other way of enabling these privileges?
Typically the reason why there is no allow.foo parameter is, that nobody
had the need yet. Jails started locked down in the past, and all the allow
parameters are there because someone had the need for it.
From a technical point of view you need to add a PR_ALLOW_xxx
(sys/sys/jail.h) and you need to extend the pr_flag_allow array
(sys/kern/kern_jail.c). After that prison_priv_check() in
sys/kern/kern_jail.c needs to be adapted.
From a security point of view this may not be enough. You do not want to
have a jail be able to do something in jails it is not supposed to own. I
do not know if this stuff is limited to the current vnet in question, or if
you could modify vnets of parallel jails (modifying child/lower jails is
ok, jails of the same or upper layer not).
The security requirements of my two use cases are different. In nested
Podman, the jailed Podman only modifies its own vnet (creating bridges and
adding/removing interfaces on those bridges) or child jail vnets (moving
interfaces into the child jails and setting addresses). The CNI plugin
use-case is different - in Kubernetes clusters, this is a trusted part of
the cluster's control plane which runs on every node in the cluster to
manage the host network configuration - on FreeBSD, this uses jail
parameter vnet=inherit to get full access to the host's network.
Thanks for the feedback - I will look into adding a new PR_ALLOW_xx flag to
enable this and open a code review.
I cannot fully follow any of this.
prison_priv_check() does list PRIV_NET_BRIDGE so you should be able to
get past that check in a vnet jail.
Likewise PRIV_NET_IFCREATE.
There's no need for any allow foo.
There once upon was a time (talk to rwatson) to make the list of allowed
priviledges configurable per jail (think MAC-alike) but that never
emerged.
I think your problem is elsehwere...
root@bhyve-freebsd:~ # jail -c host.hostname=foo vnet path=/ persist
root@bhyve-freebsd:~ # jexec 1
root@foo:/ # ifconfig lo99 create
root@foo:/ # ifconfig -l
lo0 lo99
That just works.
Did you by any chance no loade if_brige on the base system (autoloading
from within a jail won't work).
root@foo:/ # ifconfig bridge create
ifconfig: SIOCIFCREATE2 (bridge): Invalid argument
root@foo:/ # exit
root@bhyve-freebsd:~ # kldload if_bridge
root@bhyve-freebsd:~ # jexec 1
root@foo:/ # ifconfig bridge create
bridge0
Tata.
--
Bjoern A. Zeeb r15:7
