Hi，we find two underlying jails security issues to exhaust the host kernel's resources which may cause DoS attacks. The first one is we can easily exhaust the host's struct vnode in jail and reach the maxvvnodes limit. FreeBSD uses a vnode struct to represent a filesystem entity, such as a file or a directory. FreeBSD also keeps a global variable numvnodes to record the total number of vnode in the whole kernel. And the limit is in maxvnodes. The second one is we can keep producing dirty data in jail and make the dp_dirty_total of the host's zfs pool reach the zfs_dirty_data_max limit. As a result, other writing requests in the host may be delayed. Reproduction Steps: 1. We do the experiments on intel i5 CPU physical machine with 8GB memory + FreeBSD-13.0 with Ezjail-admin v3.4.2 to manage jails. 2. We use ezjail-admin to create commands to create a normal malicious jail and a victim jail, use rctl to limit the maxopnfiles and memory of the malicious jail. 3. For numvnodes(the first one issue), we just keep creating directories using `mkdir` command in the malicious jail. Host's numvnodes will keep rising until they reach the maxvnodes limit. 4. For dp_dirty_total(the second issue), we observed that the zfs_dirty_data_max limit is 800Mi, we keep writing data to a file at high speed. As a result, the host's dp_dirty_total will reach the zfs_dirty_data_max limit and cause other writing requests to be delayed. As a result, the victim-jail and host have a 46% IO performance downgrade. The kernel does not provide any isolation for the vnode or memory dirty ratio between jails. This may cause malicious jails to launch DoS attacks, thereby affecting the performance of the host or other jails
We do not consider this to be a security bug. Jails do not provide perfect resource isolation, and there are many cases beyond the vnode cache and dirty buffer pool where this is evident. Any resources utilized by a jail become unavailable to the host by definition. In the case of vnodes, numvnodes counts the number of cached vnodes. This cache is subject to an eviction policy, so reaching maxvnodes (using mkdir(1)) should not prevent the host from opening files. Similarly, ZFS imposes a limit on the amount of dirty buffers that may be accumulated, but will (eventually) make space for newly dirtied data by flushing. So I do not think that these problems result in anything other than a marginal performance degradation, which appears to agree with your report. Certainly it's desirable to have some way of limiting consumption of these resources by a particular jail (e.g., via rctl), but for vnodes at least it's not immediately obvious to me how one would go about that, since filesystem namespaces are shared with the host. Opened vnodes are not subject to reclamation in general but can be limited using rctl.