Skip to content

chore: ensure downloaded slim binary version matches server #211

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: ethan/slim-over-dylib
Choose a base branch
from

Conversation

ethanndickson
Copy link
Member

@ethanndickson ethanndickson commented Jul 31, 2025

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.

Copy link
Member Author

ethanndickson commented Jul 31, 2025

@ethanndickson ethanndickson marked this pull request as ready for review July 31, 2025 07:27
@matifali
Copy link
Member

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

cc: @deansheather

@ethanndickson
Copy link
Member Author

ethanndickson commented Jul 31, 2025

@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.

@ethanndickson ethanndickson self-assigned this Jul 31, 2025
@ethanndickson ethanndickson force-pushed the ethan/validate-slim-binary-version branch from 929c831 to 262c4d1 Compare July 31, 2025 08:07

let version: String
do {
let versionOutput = try await Subprocess.data(for: [binaryPath.path, "version", "--output=json"])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@ethanndickson ethanndickson Aug 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@ethanndickson ethanndickson force-pushed the ethan/slim-over-dylib branch from e9e15db to c7602c2 Compare August 4, 2025 02:59
@ethanndickson ethanndickson force-pushed the ethan/validate-slim-binary-version branch from 262c4d1 to a7b16ea Compare August 4, 2025 02:59
@ethanndickson ethanndickson force-pushed the ethan/slim-over-dylib branch from c7602c2 to f008801 Compare August 4, 2025 03:00
@ethanndickson ethanndickson force-pushed the ethan/validate-slim-binary-version branch from a7b16ea to 9695afe Compare August 4, 2025 03:00
@ethanndickson ethanndickson force-pushed the ethan/slim-over-dylib branch from f008801 to 847006f Compare August 4, 2025 03:03
@ethanndickson ethanndickson force-pushed the ethan/validate-slim-binary-version branch 2 times, most recently from c229789 to a723a9a Compare August 4, 2025 07:58
@ethanndickson ethanndickson force-pushed the ethan/slim-over-dylib branch from 847006f to d9255bc Compare August 4, 2025 07:58
@ethanndickson ethanndickson force-pushed the ethan/validate-slim-binary-version branch from a723a9a to ffe7d2e Compare August 4, 2025 08:05
@ethanndickson ethanndickson force-pushed the ethan/slim-over-dylib branch from d9255bc to 4f29ff3 Compare August 4, 2025 08:05
@ethanndickson ethanndickson force-pushed the ethan/validate-slim-binary-version branch from ffe7d2e to ab9ca27 Compare August 4, 2025 08:07
@ethanndickson ethanndickson force-pushed the ethan/slim-over-dylib branch from 4f29ff3 to 5840bce Compare August 4, 2025 08:07
@ethanndickson ethanndickson force-pushed the ethan/validate-slim-binary-version branch from ab9ca27 to 50e4a63 Compare August 4, 2025 09:42
@ethanndickson ethanndickson force-pushed the ethan/slim-over-dylib branch from 5840bce to 3f7f6b6 Compare August 4, 2025 09:42
@ethanndickson ethanndickson force-pushed the ethan/validate-slim-binary-version branch from 50e4a63 to 8fb9382 Compare August 4, 2025 12:53
@ethanndickson ethanndickson force-pushed the ethan/slim-over-dylib branch from 3f7f6b6 to 42b8f0b Compare August 4, 2025 12:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants