pf in a Jail

B

BawdyAnarchist

I have a vnet jail for my physical NIC. In order to start the pf service in that jail, I had to add a devfs.rule to unhide /dev/pf.
I also have wireguard jails which I intend to do the same, and connect them to my NIC-jail. (everything is vnet).

Does anyone know if this is a bad idea?
Will multiple jails having access to /dev/pf cause conflicts?
Will I have to be careful about specifying in/out to/from IP addresses associated with the jails to avoid conflicting rules?
What kind of security implications does this have?
Should I maybe run a different packet filter program? Or other solutions I am missing?
 
It's safe to use pf in multiple vnet, with different rules. I'm not going to say there are no bugs, but I consider it to be a supported use case. I run such a setup on my own machines.

You're correct about the devfs rule. It's somewhere on my todo list to actually commit that change, because there's no reason to hide /dev/pf in vnet jails (and not much of one to hide it in non-vnet jails, really).

Each vnet jail has its own IP stack, and you can largely thing of a vnet jail as its own machine (in terms of networking at least). You only need to care about the host pf rules to the extent that the jail's traffic passes through the host. That is, if you're routing/nat-ing the jail traffic you need to take that into account in the host pf rules. If you're bridging or give your vnet jails their own network interface the host pf will not affect the vnet jail traffic.

Note that running pf in a jail does not confer any additional security advantages. An exploitable bug in pf is just as severe if it happens to a vnet jailed pf as to a host pf. Running pf in a vnet jail is useful to delegate access or establish a logical division of configuration. It is not a security advantage by itself. (For example, I run pf in a jail because the jail has its own public IP address and is managed by other people than the host machine.)

ipfw and ipf also support use in vnet jails. I don't use them myself so cannot offer more advice.
 
Many thanks for the reply.

I'm trying to keep the host always offline except to apply updates. Probably a full virtual machine with PCI passthrough for the NIC would be a more secure way to do that, but I suppose I just like to live dangerously... /nerd /j.

I'm mildly re-creating some of the Qubes security conecpts via jails. Even tho pf isn't any more secure on a jail, my idea is that separating the functionality of NIC and firewall into isolated gateway jails, reduces their risk of being compromised by a downstream exploited jail.
 
BawdyAnarchist said:
Many thanks for the reply.

I'm trying to keep the host always offline except to apply updates. Probably a full virtual machine with PCI passthrough for the NIC would be a more secure way to do that, but I suppose I just like to live dangerously... /nerd /j.

I'm mildly re-creating some of the Qubes security conecpts via jails. Even tho pf isn't any more secure on a jail, my idea is that separating the functionality of NIC and firewall into isolated gateway jails, reduces their risk of being compromised by a downstream exploited jail.
Click to expand...

Updating for posterity. I will be using bhyve to create a VM for the NIC. The reason Qubes isolates the physical NIC is the potential for DMA attacks via PCI. DMA compromise on host is game-over. It's probably a low surface area attack for my NICjail, since it's doing nothing other than routing traffic. But might as well be able to consider it fully untrusted and reduce the attack surface via a full VM, since I'm going the trouble of isolating it anyways.
 
You must log in or register to reply here.
Back
Top