QEMU: is it possible to set the com.apple.vm.networking entitlement?

[tamird]

Output of brew config

N/A

Output of brew doctor

N/A

Description of issue

In qemu/qemu@bcf0a3a QEMU added support for Apple's vmnet framework. Unfortunately access to vmnet requires the com.apple.vm.networking entitlement which is not self serve:

This entitlement is restricted to developers of virtualization software. To request this entitlement, contact your Apple representative.

The absence of this entitlement from QEMU binaries is also noted in https://gitlab.com/qemu-project/qemu/-/issues/1364.

I've written a patch to allow QEMU's build system to generate binaries with this entitlement, but this requires a provisioning profile which has been approved for this entitlement. I don't know how Homebrew's infrastructure manages such secrets, if at all - but would such a thing be possible? I imagine the blessed provisioning profile would need to be guarded in some way so that only QEMU (and perhaps other allowlisted software) could be endowed with this entitlement.

Thanks for your help!

[SMillerDev]

Anything that Homebrew builds will also be the way that it builds on people's computers.

[alebcay]

I took a look over at the QEMU issue that was linked, https://gitlab.com/qemu-project/qemu/-/issues/1364. Homebrew does not have a paid developer account for which it uses to sign binaries; binaries are ad-hoc signed on the end user's machine after a package is installed.

Note that ad-hoc codesigning is only valid for the machine on which the signing occurs (at least, on more recent machines; I think this may be more lax on some older Intel machines but we can think about the more strict scenario). We cannot ad-hoc codesign binaries in CI and then distribute them and have them work as-is; that's why it is done on the end-user machine side.

If the com.apple.vm.networking entitlement can work with ad-hoc codesigning (which does not require a paid developer account), then my suggestion would be:

• Add the com.apple.vm.networking entitlement in an appropriate file in the QEMU source tree (or append to the existing entitlements.plist that is maintained there). The build system that QEMU uses should be responsible for applying the appropriate entitlements to the appropriate binaries (and, in the process, ad-hoc codesigning the binaries - this already seems to happen in the QEMU entitlement.sh script).
• Homebrew will (re-)ad-hoc codesign the binaries for the end user thus making the binaries trusted on the end users' machine. The entitlement should be preserved, since Homebrew (re-)ad-hoc codesign includes --preserve-metadata=entitlements.

I haven't fully tested these steps before, but this is how we have been handling the existing com.apple.security.hypervisor, and, assuming that this new entitlement does not need to be handled differently than the existing one, I would hope that the same approach works too.

---

If the com.apple.vm.networking entitlement only works with a paid developer account/identity, then Homebrew does not offer a service or identity to be "loaned out" to codesign the binaries.

[tamird]

Indeed com.apple.vm.networking is not like com.apple.security.hypervisor. Whether or not payment is required I don't know, I think the folks over in the QEMU issue were speculating on this point. But we definitely can't bestow this entitlement in the usual manner (presumably because this one allows arbitrary network packets to be crafted, which can be a security hazard).

[alebcay]

I see. Well, I guess my main point is that Homebrew currently does not have another manner for granting entitlements apart from the approach that already seems to be used by QEMU.

[p-linnane]

We do not have a mechanism to do this, nor would we want to be distributing provisioning profiles.