On 2022-12-01 08:37, Alan Somers wrote:
I don't care for any of it. It looks like additional overhead with the addition of potential security risks. All for a very limited (and as yet unknown) use case.Here's an example of a real-world use case. I'm responsible for supporting multiple products involving NFS, iSCSI, and other protocols. For security reasons, each product is placed on its own VLAN. Sometimes it's not practical to dedicate a physical server to a single product, so I have to double-up. For the products that don't involve NFS or iSCSI, I place them in a VNET jail. That way their processes can only access the correct VLAN. But NFS and iSCSI can't (yet) be jailed, so those products need to be served by JID 0. Therefore, those products' processes can access each other's VLANs. Clearly that's not ideal. Jailing different products is also good for manageability. It's easier to manage the list of packages that must be installed for each product, config file settings, etc. For example, some of our NFS products require vfs.nfsd.enable_stringtouid=1, but others could work without it. Right now, we're forced to turn it on for all products.
OK. I can see that. Assuming I understand your intent correctly, I might choose bhyve(8) for that. Tho that *would* be a little more expensive. I rely on jail(8) daily. They're cheap, fast && easy. As yet, I've never had unreasonable concern for security. The proposed change looks like a potentially high addition of overhead (jail not so cheap now?). RPC && NFS are not cheap && have a comparatively high attack surface. So I guess my concerns/view are affected by this understanding. Thanks for the clarification, Alan. --chris
-Alan
0xBDE49540.asc
Description: application/pgp-keys
