security: keep automatic HTTPS and remote agent control loopback-only, harden app-side local CA - #67
Open
devin-ai-integration[bot] wants to merge 1 commit into
Open
Conversation
…, harden local CA Co-Authored-By: Augustus Otu <Augani7@gmail.com>
Author
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Security scan of the repo (secrets, injection, dependencies, CORS, debug endpoints, auth) turned up four real issues, all in the local-HTTPS and remote-agent paths. Most scan categories came back clean: no SQL anywhere, no CORS middleware, no debug/admin endpoints,
npm auditclean, and the Rust audit gate already handles the only advisory (RUSTSEC-2023-0071, RSA not compiled). XPC entry points already authenticate peers (same-UID + pinned production signature), the guest vsock listeners already reject non-host CIDs, andexecpaths use argv arrays, not shells.1. Automatic HTTPS was reachable from the LAN (high). Both TLS proxies use
NWListener, which has no bind-address knob, so unlike the plaintext proxy (explicit127.0.0.1bind) they accepted any peer — anyone on the network could reach every container/k8s backend by sending aHost: *.dory.localheader to the HTTPS port. Loopback bind is not an option::443only binds unprivileged on the wildcard address, which is exactly whyLoopbackTCPForwarderalready listens wildcard and filters peers. Both proxies now do the same, failing closed on anything not recognisably loopback:2.
dory-agent --daemon <addr>could serve unauthenticatedExecon a routable address (high). The control protocol has no in-band auth by design; safety comes entirely from the loopback default plus doryd's SSH tunnel, previously enforced only by a comment.daemon::servenow enforces it at both ends — mirroring the guest server'sis_host_peerpolicy:3. The app-side
LocalCA(Dory/Net/LocalCA.swift) was materially weaker than itsDorydKittwin (medium). It signs the CA the user is asked to trust in their login keychain, yet wroteca.key/leaf keys with default (world-readable) permissions, interpolated caller-supplied domains straight into the opensslsubjectAltNamestring, and passed the PKCS#12 passphrase in argv (visible viaps). Brought in line withDorydKit/LocalCA.swift:umask(0o177)around CA generation plus0600keys,validateCertificateNameon the domain and every extra SAN (rejects commas, path separators, empty labels), and-passout env:DORY_LOCALCA_P12_PASSvia a new optionalenvironment:argument onShell.run.4. Hardcoded PKCS#12 passphrase
"dory"(low, but a literal secret).AppStore.startTLS()issued and loaded the TLS identity with a compiled-in password; it now generates a per-start random one viaAppStore.ephemeralIdentityPassword(), the same 24-byte patternNetworkingControlleralready uses.All four are locked in by new
test-security-contracts.shassertions (including a repo-wide grep forpassword: "dory"), plus Rust unit tests for the loopback predicates and Swift tests for the peer filter, key permissions, SAN validation, and password randomness.Verified on Linux:
cargo fmt --check,cargo clippy --workspace --all-targets,cargo test --workspace(all green, new daemon tests included),test-rust-security.shPASS,test-security-contracts.shPASS. The Swift changes cannot be compiled here (Network/Security/Darwin are macOS-only) and rely on CI.Link to Devin session: https://app.devin.ai/sessions/9247634b01b94efda78e09735c0e2fd1
Requested by: @Augani