In D49843#1138954, @netchild wrote:

In D49843#1138774, @zec wrote:

In D49843#1138772, @netchild wrote:

In D49843#1138771, @zec wrote:

...

No, the host is gone as well, since the attacker has control over network connectivity.

You go to the keyboard of the host, delete the jail, and the attacker is gone.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Sounds pretty much as a very deep redefinition of the jail contract to me.

Apart from jamies comment, How is this different from any other daemon running as root in a jail? If you can take over any externally reachable service in a jail, it is over. You need to delete the jail and start fresh (with a fixed daemon).

In D49843#1138772, @netchild wrote:

In D49843#1138771, @zec wrote:

...

No, the host is gone as well, since the attacker has control over network connectivity.

You go to the keyboard of the host, delete the jail, and the attacker is gone.

In D49843#1138763, @ivy wrote:

In D49843#1138751, @zec wrote:

Consider an exploit in BIRD which would allow routing tables to be manipulated

consider an exploit in BIRD which would allow an attacker to run code as root.

running BIRD in a jail -> only the jail is compromised.

Repeating that someone might have his mind set on running BIRD in a swiss-cheese-jail is far from providing arguments on what real security benefit would this provide compared to running it in a plain system (or in a chrooted tree).

I've been running routing daemons in VNET jails with chroot=/ myself for more than two decades, so have nothing against chroot=/ jails per se. But this is pushing in the opposite direction, having routing daemons running in pseudo-jails with very weak isolation.

This change depends on https://reviews.freebsd.org/D49843, which is still contentious and unresolved.

Will other routing daemons, which manage not only routing tables, but also system interfaces and their addresses, work 100% happily in this new ALLOW_ROUTING jail, or is this hack BIRD specific? What if BIRD folks one day decide to start adding direct interface management capabilities there, should we then follow up with punching more holes and start adding ALLOW_IFADDR, ALLOW_IFUPDN etc. etc. And if so, where's the boundary, where do we stop?

In which application scenarios could allowing jailed processes to take command of system's routing tables be considered useful / desirable?

In D49158#1121338, @glebius wrote:

I do not like the plan. The picture drawn shows that a netgraph node in one vnet is connected to a node in a different vnet. This is basically a violation of the idea of vnet. Virtualized stacks should communicate with each other via network protocols, not kernel pointers. The only legal exclusion is epair(4).

By design, moving an eiface ifnet from one vnet to another always implied that its netgraph node will remain attached in the parent vnet. This is not an omission or a mistake, but a well established mode of operation on which certain applications heavily depend on, and which this patch proposes to change, for reasons not clearly stated.

This change builds on top if_index globalization (91f44749c6feb50f39af8805dd803e860f0418f1) which I strongly objected to, and which glebius agreed to back out as outlined in https://github.com/glebius/FreeBSD/commits/backout-ifindex, but that never happened. Hence, pls. don't proceed with this until if_index is reverted back to per-VNET state.

In D29821#677630, @zarychtam_plan-b.pwste.edu.pl wrote:

function dxr_build with caller dxr_change_rib_batch seems to be still active