VNet daemon: Set code signing requirements

[ravicious]

This PR makes sure that only tsh signed by us can contact the VNet daemon and that the VNet daemon is executed from a tsh binary signed by us.

It achieves this using setCodeSigningRequirement and setConnectionCodeSigningRequirement which ensure that the designated requirement of the app on the other side of an XPC connection satisfies a certain requirement.

A detailed breakdown of what constitutes a matching requirement is documented in the code. But in short, the requirement boils down to "an app with the same code signing identifier and the team identifier as me, signed by a Developer ID Application cert issued by Apple".

To extract the code signing identifier and the team identifier out of the currently running code, we use SecCodeCopySelf and SecCodeCopySigningInformation. Those are APIs from the Code Signing framework written in C and use Core Foundation framework. This means that there's a lot of auxiliary code related to memory management. I documented every step to make this easier to understand, but it does require an understanding of a couple of key Obj-C characteristics (I do link to docs explaining them).

Verifying the client

Video

unsigned-client-calling-daemon.mov

This is seems to be the more important half of this PR. The VNet daemon exposes privileged APIs to unprivileged processes, so we don't want just any program on the device to be able to talk to the daemon.

In the video, a client that has not been signed at all attempts to talk to the daemon. Since we tell the listener to place a requirement on each new connection, the connection gets interrupted before it even gets to the daemon. So launchd spawns the daemon, but the daemon never receives the message nor knows about the connection attempt.

This poses a problem from the perspective of being able to easily debug this. Since the XPC service never learns about this connection, we cannot log this attempt on the daemon side. The client side does not get informed that it does not match the code signing requirement. It merely gets informed that the connection was interrupted. As such, when the client sees that the connection was interrupted, I log a debug message pointing towards Console.app to check the reason behind the interruption.

I made a thread on the Developer Forums asking if there's a way to detect this, but so far it doesn't seem like it's possible.

Verifying the daemon

Video

daemon-with-wrong-code-sign-req.mov

Here's a demo of the client verifying that the daemon can be trusted. To simulate a daemon with wrong code signing requirement, I modified the requirement passed to setCodeSigningRequirement so that it's impossible to match.

It's harder to understand what exactly macOS does in this scenario and it isn't well documented. In the video you can see that the connection between the client and the daemon gets established, but it's interrupted soon after. The daemon gets the message from the client and executes its own handler for that message. This passes the socket back to Go code on the daemon side and creates a TUN device, which is then passed to the client. The client proceeds to use the TUN device.

This all happens in a separate goroutine while the startVnet method of VNEDaemonClient waits for the completion block to be called by the daemon. Instead, it gets back an error. This makes the client return early and shut down. The daemon sees that the client was shut down and stops execution as well.

The hard to understand part is that I don't know if it's guaranteed that the interruption happens within the block where the client calls the daemon or not:

teleport/lib/vnet/daemon/client_darwin.m

Lines 111 to 123 in 2db4bc0

	- (void)startVnet:(VnetConfig *)vnetConfig completion:(void (^)(NSError *))completion {
	// This way of calling the XPC proxy ensures either the error handler or
	// the reply block gets called.
	// https://forums.developer.apple.com/forums/thread/713429
	id proxy = [self.connection remoteObjectProxyWithErrorHandler:^(NSError *error) {
	completion(error);
	}];
	[(id<VNEDaemonProtocol>)proxy startVnet:vnetConfig
	completion:^(NSError *error) {
	completion(error);
	}];
	}

According to my tests, it seems that the connection gets invalidated after the daemon calls the completion block passed from the client, but before the result of it gets back to the client. As in, it's always [self.connection remoteObjectProxyWithErrorHandler] that calls completion with an error first.

What was easier to implement in this scenario is that when the daemon does not satisfy the requirement, the client gets a clear information about it through the NSXPCConnectionCodeSigningRequirementFailure error code.

The client could be refactored to wait for the full dance between it and the daemon to be complete before attempting to use the TUN device. However, this adds further complexity to an already complicated system dealing with async stuff.

[ravicious]

This is a C function working on Obj-C objects, which I think is fine.

From what I understand, the pattern with passing stuff by reference is common when you want to "return" more than one thing. This is especially common when it comes to NSError. https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/ErrorHandling/ErrorHandling.html#//apple_ref/doc/uid/TP40011210-CH9-SW5

[codingllama]

Thanks for the detailed explanation. It all makes a lot more sense because of it.

[codingllama]

I've run into problems before with multiple #cgo declarations in the same package. You might want to have all import "C" related stuff in a single file. Just a word of caution.

[ravicious]

I removed #cgo declarations from all files but common_darwin.go. bc3e9f5

[public-teleport-github-review-bot]

@ravicious See the table below for backport results.

Branch	Result
branch/v16	Create PR