chore: ensure downloaded slim binary version matches server

[ethanndickson]

Relates to #201.

After we've validated the binary signature, we exec coder version --output=json to validate the version of the downloaded binary matches the server. This is done to prevent against downgrade attacks, and to match the checking we had on the dylib before.

Additionally, this PR also ensures the certificate used to sign the binary is part of an Apple-issued certificate chain.

I assumed we were checking this before (by default) but we weren't.
Though we weren't previously checking it, we were only ever downloading and executing a dylib.
My understanding is that macOS won't execute a dylib unless the executing process and the dylib were signed by the same Apple developer team (at least in a sandboxed process, as is the Network Extension).

Only now, when posix_spawning the slim binary from an unsandboxed LaunchDaemon, is this check absolutely necessary.

[ethanndickson]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• chore: set minimum coder server version to v2.25.0 #215
• fix: start coder connect progress indicator immediately #214
• chore: ensure downloaded slim binary version matches server #211 👈 (View in Graphite)
• chore: use slim binary over dylib #210
• fix: add code signing requirements to xpc connections #206 : 1 other dependent PR (#209 )
• chore: run coder connect networking from launchdaemon #203
• chore: make helper launchdaemon approval mandatory #205
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[matifali]

Not directly related but @jdomeracki-coder should we also implement binary verification in Coderd Desktop?

cc: @deansheather

[ethanndickson]

@matifali We already check the code signature for both mac and Windows, it was part of the RFC.
It's even more important for Coder Desktop because the process runs as root.

[deansheather]

Any way to drop privileges for this subprocess? We are root after all...

[ethanndickson]

This is possible with a combination of launchctl asuser <uid> and sudo -u [<uid>|<username>]:

sudo -u '#501' launchctl asuser 501 /usr/bin/whoami

One switches the UID, the other the (macOS specific) execution context.

Unfortunately,

$ sudo -u nobody launchctl asuser -2 /usr/bin/whoami
Could not switch to audit session 0x187c3: 1: Operation not permitted

does not work, and so we'd need to determine the currently logged in user in some other way.
501 is the first created user on the machine, and on corporate devices this will likely be some admin user.

[deansheather]

It's fine to execute it as root if it's too difficult, the signature is still ours so the risk is small