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. > Bye, > Alexander. > -- > http://www.Leidinger.net [email protected]: PGP 0x8F31830F9F2772BF > http://www.FreeBSD.org [email protected] : PGP 0x8F31830F9F2772BF >
