xhyve being used by Go console application

Summary
We a Go console application, that uses xhyve to start up a VM and do some processing and are trying to get networking to function without having xhyve setuid 0 by giving it the `com.apple.vm.networking` entitlement. Is this possible and the correct direction we should be looking? This would not be an App Store distributed file.

Details

We have built xhyve with xcode, signed it, added entitlements, etc... It gets killed quickly. We're thinking this is the notorization process that's killing it now that it's signed and it's just dying out before getting anywhere. Creating a ZIP that contains the binary, uploading that ... and then trying to staple that successful build fails (hash missmatch) since we can's specify a specific a specify notoriztion history UUID (i.e. xcrun stapler staple -n [UUID] [file] ).


What does work is building xhyve the standard `make` way. Setting the xhyve binary suid 0, so we execute with root priviledges. We do not want to add any root priviledge escalations in (or root daemon process) though, and from my understanding, the `com.apple.vm.networking` entitlement should allow this networking without needing root priviledges.


For the notorization process... would we need to create a `.app` (is there a console way to do this??), sign every binary we have (even the Go binaries). Upload that `.app` to be notorized, and then staple?


If `com.apple.vm.networking` is the wrong entitlement to be looking at, what would be a better one?


We are developing a console application ... not a sandboxed application. It's something the user would run from a Terminal session out of /usr/local, etc... So, is it even feasible to do this with what we're developing?


Thanks,

-J

Replies

We … are trying to get networking to function without having xhyve setuid 0 by giving it the

com.apple.vm.networking
entitlement. Is this possible and the correct direction we should be looking?

Yes, and no. This entitlement will do what you need, but you won’t be able to use it without permission from Apple. In general, entitlements must be whitelisted by a provisioning profile [1]. For a standard entitlement you use the developer web site (or the Capabilities editor in Xcode) to set the entitlement on your App ID. This entitlement is then incorporated in any provisioning profile you generate from that App ID.

However,

com.apple.vm.networking
is a special entitlement, one that you can’t enable via the developer web site. Such entitlements must be explicitly granted to you by Apple. You can do that by dropping DTS a line [2]. However, I have to set some expectations here.
com.apple.vm.networking
was intended to allow VM apps to ship in the Mac App Store (where privilege escalation is outlawed) and thus it’s going to be a hard sell for non-app products shipping outside the store.

With regards your notarisation issues, please start a new thread over in Distribution > Mac Apps and I’ll take a proper look there.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

[1] Although certain entitlements, like the ones used in the App Sandbox, do not require whitelisting.

[2] You’ll need to open a tech support incident, but we’ll return that incident to your account because this is purely administrative.