markjdb
commented
5 months ago Hi Seth, I'm glad the slirp backend is useful to you. I didn't have any plans to change anything since my needs are simple and covered by the existing functionality.
As you note we hard-code the the 10.0.2.0/24 subnet in the slirp parameters for each subnet. To start, we should at least automatically create a new subnet for each interface. In the absence of any explicit configuration, I'm inclined to make each interface use 10.0.X.0/24 with X=2 for the first interface, and autoincrementing up to X=254, beyond which one would need to explicitly specify the desired subnet somehow. Does that seem reasonable to you?
To disable DHCP, I propose letting disable_dhcp be a key in the slirp configuration, so one can write slirp,hostfwd=...,disable_dhcp,.... Maybe it would be better to have an explicit flags=disable_dhcp,... key-value pair, I'm not sure. I think I prefer the former.
Dropping privileges after VM initialization is likely a good idea, though bhyve's Capsicum sandbox should in principle provide even stronger protections, so I don't immediately see any examples of attack vectors that would be closed by that change. It is still useful as a defense-in-depth measure at least. That's somewhat orthogonal to rootless bhyve IMO, but it should be easy to implement this as a part of that project.
PHSpline
Hi @markjdb, thanks for implementing slirp backend support in bhyve. Are there any plans to allow for the various SlirpConfig parameters to be overridden? Currently it seems as though the DHCP range is hardcoded, resulting in the same 10.0.2.15 IP being assigned to each slirp interface in the case where multiple slirp-backed interfaces are used within a single VM. It's easy enough to assign a static IP to the interfaces but it'd be cool if I could have each interface be assigned IPs from different subnets, via DHCP.
Additionally, it would be neat if the DHCP server could be disabled per interface as well (disable_dhcp parameter in SlirpConfig) in the case of bridging multiple slirp-backed interfaces together and wanting only one to have an active DHCP server. Likely a niche use case, but I can't help but think about it for completeness.
Another thought I had was regarding the rootless bhyve stuff - would it be feasible to also allow a mode where bhyve starts out as root to configure networking and then immediately drops privileges to a non-root user using e.g. setuid/setgid? This way, the more performant netgraph backend could still be used while also reducing root user exposure.