Agent: any same-user process can sign during the unlock window; no per-signature re-authentication

[bordumb]

Summary

The signing agent in auths-core holds unlocked private-key material and serves signature requests over a
Unix-domain socket. Connection authorization is by peer UID only. This correctly rejects other users,
but it means any process running as the same user can connect during the unlock window and obtain
signatures over arbitrary payloads — and there is no per-signature re-authentication (no biometric /
Secure-Enclave user-presence check, no approval prompt). A single unlock grants silent, blanket signing to
every local process the user runs, for the duration of the window.

Where (code)

Caller authorization — crates/auths-core/src/agent/session.rs:299:

fn peer_is_authorized(peer_uid: u32, owner_uid: u32) -> bool {
    peer_uid == owner_uid
}

This is the only caller gate (it is fed by an SO_PEERCRED / getpeereid check on the connecting socket). It
does not distinguish processes of the same user.

Unlock window — crates/auths-core/src/agent/handle.rs:15 and :19:

pub const DEFAULT_IDLE_TIMEOUT: Duration = Duration::from_secs(30 * 60);       // sliding; resets on each sign
pub const DEFAULT_MAX_UNLOCK_TTL: Duration = Duration::from_secs(8 * 60 * 60); // absolute cap

During this window the agent signs any request from a same-UID connection. The signing path
(AgentSession::sign in crates/auths-core/src/agent/session.rs) performs no per-request re-authentication
beyond confirming the agent is unlocked.

Threat / scenario

1. The user unlocks the agent once (passphrase / initial approval).
2. Any other process running as that user — a malicious dependency, a compromised build tool, a script —
   connects to the agent's Unix socket.
3. It sends a sign request with attacker-chosen bytes and receives a valid signature attributable to the
   user's identity.
4. This succeeds silently for up to the unlock window (default 30 min sliding idle, 8 h absolute), with no
   prompt or biometric.

Already in place (do not regress)

• Socket directory is 0o700, socket file 0o600, with fail-closed handling of pre-existing loose
  permissions (crates/auths-core/src/api/runtime.rs, functions harden_socket_dir / harden_socket_file).
• Cross-user connections are rejected (the UID check above).
• Locking clears in-memory keys; both idle and absolute caps exist and are tested.

The gap is specifically: same-user callers + no per-use confirmation.

Proposed remediation (pick / combine)

1. Per-signature (or per-new-peer) user approval. Require an explicit user action — OS notification /
   TUI prompt / Touch ID — to approve each signature, or at least the first request from each newly
   connecting process. (ssh-agent's confirm mode and password-manager per-request approval are the model.)
2. Per-signature biometric / Secure-Enclave user-presence. When the key is SE-backed, require a Touch ID
   / enclave user-presence check per signature (or per N signatures), not only at initial unlock.
3. Caller pinning / allowlist. Record the first authorized peer (pid + executable path / code-signing
   identity) and require explicit approval when a different same-user process connects.
4. Tighten defaults. Shorten the 8 h absolute cap and/or add a max-signatures-per-unlock counter.

Full defense against same-UID malware is not achievable without OS-level isolation; the realistic goal is
that obtaining a signature requires user interaction, so one unlock does not equal silent blanket signing.

Acceptance criteria

• A same-user process connecting mid-window cannot obtain a signature without the chosen approval/biometric
  step.
• A test under crates/auths-core/tests/cases/ that drives the real socket and asserts a second connection
  cannot sign without that step (mirroring the existing agent_socket.rs socket tests).
• Existing cross-user rejection and lock-clears-keys tests still pass.

Severity

High. The agent exists to hold signing capability; "one unlock → silent blanket signing for any local
process you run" is the realistic local-compromise path.

[bordumb]

Design decision + impact analysis (before implementation)

Working this on branch fix/agent-354-per-request-auth. One investigation finding shapes the whole approach:

The agent here is the SSH-agent used for git commit signing (crates/auths-core/src/ports/ssh_agent.rs, crates/auths-core/src/crypto/ssh/*, AgentSession: ssh_agent_lib::agent::Session). It is not the path auths sign uses — auths sign (crates/auths-cli/src/commands/artifact/sign.rs) decrypts the key directly from the keychain and never contacts the agent. The agent is also consumed by autonomous signers (the MCP gateway).

Impact (why a blanket prompt is wrong)

• CI is unaffected. Release/artifact signing goes through the direct-decrypt path, not the agent. An agent-side approval gate cannot break it. (Only a headless job that explicitly starts and signs through the agent would be affected — handled by an explicit non-interactive policy.)
• Autonomous / MCP would break under unconditional approval. An AI agent brokering signed calls cannot do a biometric; its authority is the delegation/scope, not a human touch. So approval must be a policy, with an explicit non-interactive mode for those contexts.
• Developer friction. Because this is the git-commit path, a per-signature biometric would be miserable (a 30-commit rebase = 30 prompts).

Chosen policy: per-caller approval (not per-signature)

Approve/biometric once per new connecting process; pin it; that caller signs freely within the unlock window; a different/unexpected process triggers a fresh approval. This closes the #354 silent-arbitrary-process path while keeping legitimate commits frictionless.

Platform nuance (important): the peer PID is available on Linux (SO_PEERCRED) but not on macOS (getpeereid returns uid/gid only — no pid). So:

• Linux: pin the approved caller by (uid, pid).
• macOS: cannot identify the calling process, so fall back to a time-bucketed biometric re-auth (approve at most every N minutes) layered on the existing per-unlock auth.

Shape of the change

• A SignAuthorizer hook in auths-core the agent consults before every sign; deny ⇒ refuse with a new AgentError. Core stays I/O-free.
• The biometric/prompt + per-caller pinning is a host-provided implementation injected at the CLI/runtime boundary (where the Secure Enclave / prompt lives).
• Autonomous / headless / tests inject an explicit allow-within-window authorizer (also keeps the existing socket tests green).

TDD

First failing test (pure auths-core, platform-independent): the agent must refuse to sign when the injected authorizer denies. Today it signs unconditionally inside the unlock window, so it fails now; the fix threads the authorizer through the sign path. Per-caller pinning + biometric are then built/tested on top.

[bordumb]

Implementation note: the biometric approval backend can live entirely in auths-cli — no separate signed release

Earlier I flagged a distribution concern (code signing / notarization) for the daemonized Touch ID prompt. That concern is misplaced for cargo install — the backend can be fully native and contained in auths-cli. Details, so it's on the record:

Why it works natively via cargo install:

• A binary built locally by cargo install is not Gatekeeper-quarantined (quarantine is only applied to downloaded files). It runs with the ad-hoc signature the linker applies, no notarization needed.
• A non-sandboxed CLI tool can call LocalAuthentication (LAContext.evaluatePolicy) and Secure Enclave for the local user without a paid entitlement.
• Proof it already works: auths triggers a native Touch ID dialog on commit today, from a locally-built / cargo install'd binary — via the existing Secure-Enclave signing path (crates/auths-core/swift/SecureEnclaveBridge.swift::se_sign using LAContext; crates/auths-core/build.rs links the LocalAuthentication framework).

So the #354 daemon backend is the same mechanism: port the standalone LAContext prompt (prototyped and verified on-device — see the account-setup simulation) into a Rust→Swift FFI approve backend alongside SecureEnclaveBridge.swift, and inject it from build_sign_authorizer for the non-TTY/daemonized case. Nothing leaves auths-cli; no separate installer.

Signing/notarization would only matter if we shipped prebuilt, downloaded binaries (a Homebrew bottle / DMG → Gatekeeper quarantine). It does not apply to cargo install (self-compiled).

Honest scoping nuances to keep in mind while building it:

• The existing per-commit Touch ID is per-signature, enforced by the SE key. Agent: any same-user process can sign during the unlock window; no per-signature re-authentication #354's per-caller approval is a different trigger — approve a calling process once, then it signs within the unlock window without re-prompting.
• The silent-signing gap Agent: any same-user process can sign during the unlock window; no per-signature re-authentication #354 addresses is mainly for software keys cached in the agent. An SE-backed key in the agent still prompts per signature (the enclave enforces user presence regardless of who holds it), so it has no silent-signing gap.
• For any dialog to appear, the agent must run as a per-user LaunchAgent (has a GUI session). A system LaunchDaemon (no session) cannot show Touch ID — independent of signing.