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]

• chore: set minimum coder server version to v2.24.3 #215
• fix: always open app as logged-in user in postinstall script #216
• 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

[Copilot]

Pull Request Overview

This PR enhances the security validation of downloaded Coder CLI binaries by adding version validation and strengthening certificate chain verification. The changes prevent downgrade attacks by ensuring the downloaded binary version matches the server version, and add explicit Apple certificate chain validation.

Key changes:

• Split validation into separate signature and version validation functions
• Add binary version validation by executing coder version --output=json
• Strengthen certificate validation to require Apple-issued certificate chain

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
Coder-Desktop/VPNLib/Validate.swift	Refactors validation logic, adds version validation function, and enhances certificate chain requirements
Coder-Desktop/Coder-DesktopHelper/Manager.swift	Updates to use new two-step validation process (signature then version)

[ethanndickson]

Merge activity

• Aug 6, 3:39 AM UTC: A user started a stack merge that includes this pull request via Graphite.
• Aug 6, 3:52 AM UTC: Graphite rebased this pull request as part of a merge.
• Aug 6, 3:53 AM UTC: @ethanndickson merged this pull request with Graphite.