swallow/maestro
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
maestro/SECURITY.md
oss-sync b411151bad
Some checks failed
CI / build-and-test (push) Has been cancelled
Details
sync: update from private repo (0844939)
2026-06-16 03:35:01 +00:00

2.8 KiB
Raw Blame History

Security Policy

Supported Versions

Security fixes are applied to the latest release and the main branch.

Reporting a Vulnerability

Do not open a public issue for an undisclosed vulnerability. Use the repository host's private security-reporting feature when available, or contact the repository owner privately. Include affected versions, impact, reproduction steps, and any suggested mitigation. Maintainers should acknowledge a report within seven days and coordinate disclosure after a fix is available.

Deployment Baseline

MAESTRO can execute tools, browser actions, and optionally SSH commands. Treat it as a privileged service:

  • Keep the service bound to localhost until OAuth authentication is configured.
  • Put internet-facing deployments behind a TLS reverse proxy.
  • Set safety.bash_sandbox: always for multi-user deployments.
  • Keep MCP_ENCRYPTION_KEY, OAuth secrets, SSH keys, and provider credentials outside the repository and rotate them after suspected exposure.
  • Restrict /metrics with a bearer token or an explicit source-IP allowlist.
  • Review enabled tools and integrations before granting access to untrusted users.

Secrets and Data

MAESTRO generates and stores several secrets. All of them live under the runtime data directory and are created with restrictive permissions:

Secret Default location Mode
Master encryption key (envelope encryption for MCP/SSH credentials) data/secrets/master.key 0600
MCP credential key data/secrets/mcp.key 0600
Session secret (signs login cookies; auto-generated when auth.session_secret is unset) data/secrets/session-secret.key 0600
Web Push (VAPID) keypair data/secrets/vapid.json 0600
Self-signed TLS material data/tls/ 0600 keys

config.yaml may hold a provider api_key, so the setup tooling writes it 0600. These paths are excluded from version control (.gitignore) and from the Docker build context (.dockerignore); never commit them or bake them into an image.

Operational guidance:

  • Set a stable auth.session_secret (or rely on the persisted data/secrets/session-secret.key) so restarts don't invalidate sessions; in a multi-node deployment, share the same secret across nodes.
  • The data directory is sensitive. Back it up with the same care as a password store; restrict filesystem access to the service user.
  • Core dumps are excluded from the repository because they can contain the decrypted master key, SSH private keys, and the session secret in process memory. Keep them out of any artifact you share.
  • Rotate after suspected exposure and review the audit log.
  • Sensitive values are masked in the Settings UI and the config API responses; do not paste unmasked secrets into issues or logs.