mirror of
https://github.com/odysseus-dev/odysseus.git
synced 2026-10-28 09:44:39 +00:00
dev
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  
|
57a1859f08 |
fix(security): stop the agent from re-enabling tools an admin disabled (#6357)
* fix(security): stop the agent from re-enabling tools an admin disabled settings.json:disabled_tools is the only global tool-permission boundary the Settings > Agent Tools panel offers, yet manage_settings exposed an `enable_tool` action that removed entries from it. Any agent turn could undo the admin's restriction, and because the agent reads untrusted web pages, emails and documents, a planted instruction could re-enable bash, email or any other tool that had been switched off. The denylist can now only be narrowed from a turn: `disable_tool` and `list_tools` keep working, `enable_tool` is refused with a message that points the user to Settings > Agent Tools, and the action is dropped from the function schema, the prompt rule and the tool index so models are not steered into calling it. The free-form set/delete/reset actions were already unable to reach `disabled_tools`; a test now pins that. Fixes #5523 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UAB5sz5srMKR7rbeDFtdMH * fix(settings): close internal API tool-policy bypass Refuse global tool-policy replacement from internal-token requests even when an admin owner is impersonated, and block the same write in app_api. Route explicit image re-enable requests to list_tools with a Settings pointer. Keep disabled_tools outside general settings actions even if a default is added later. Remove the retired action from capability metadata. Validation: 573 focused tests passed; the running app rejected handler, generic API and encoded-path internal HTTP attempts while preserving human administrator controls. * fix(mcp): block agent writes to per-server MCP tool policy PATCH /api/mcp/servers/{id}/tools only checked require_admin, which accepts the internal tool token, and app_api still forwarded it, so an agent turn could re-enable MCP tools an admin had switched off. Refuse the internal token on that route (same check as POST /api/tools) and add PATCH /api/mcp/servers to the app_api blocklist, with regression tests. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BCbhLNC7mJsunxqfwwshqn --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> Co-authored-by: Afonso Junior <chatgpt@yack.com.br> |
||
|
4d0610a1eb |
fix(email): guard user-supplied IMAP/SMTP hosts against SSRF (#6355)
* fix(email): guard user-supplied IMAP/SMTP hosts against SSRF POST /api/email/accounts/test opened raw imaplib/smtplib connections to whatever host:port the request body named, and POST/PUT /api/email/accounts and PUT /api/email/config persisted arbitrary hosts for the background pollers to contact. All of these sit behind require_user/require_owner with no admin gate, so any authenticated user could make the server connect to loopback, LAN and cloud-metadata targets (169.254.169.254) and read the first 200 characters of the remote banner back out of the friendly error. THREAT_MODEL.md lists email as admin-only; the tool layer honours that but the HTTP routes did not. Add check_outbound_host() to src/url_safety.py, a bare-host companion to check_outbound_url() with the same classification (link-local, multicast, reserved and unspecified always rejected; private/loopback only with block_private) plus localhost-name handling and an explicit policy for names that do not resolve. Wire it into the four email routes via _check_mail_host(): non-admin owners (and everyone when EMAIL_BLOCK_PRIVATE_IPS=true) also lose private/loopback targets, admins keep the local-first LAN/Dovecot setups. Unresolvable names pass through because the connect that follows fails with the same DNS error. Regression tests cover the helper's policy table and each route: the test route rejects before any socket opens, save routes reject before touching the DB, admins keep loopback unless locked down, and an update that fails validation leaves the stored row untouched. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TwcwfY2uQMxNRsK3y6xBAp * fix(email): harden IMAP/SMTP SSRF protection against rebinding, TOCTOU, and unvetted hosts - P0: Implement safe_create_connection() in src/url_safety.py to resolve hostnames once, validate every returned address against SSRF policy, and connect directly to the pinned IP. This eliminates DNS rebinding and TOCTOU while preserving TLS SNI and certificate hostname verification across IMAP, IMAPS, STARTTLS, SMTP, and SMTP_SSL. - P1: Ensure unresolvable or deferred hostnames cannot become an unrestricted future connection capability by enforcing runtime SSRF validation fail-closed on every connection, while maintaining compatibility with offline configurations. - P2: Extend SSRF enforcement to the core connection layer (_open_imap_connection, _send_smtp_message, _imap_connect) using ContextVar owner scoping, protecting pre-existing DB rows, restored configs, background pollers, and scheduled operations. - P3: Allow admin and single-user access to IPv6 loopback (::1, [::1]) for local mail servers (e.g. Dovecot) by checking loopback before is_reserved, while keeping link-local, cloud metadata (169.254.169.254, 100.100.100.200), and non-admin restrictions strictly enforced. - Add comprehensive regression and adversarial test coverage in tests/test_email_account_host_ssrf.py. * fix(email): reject unresolved saved hosts without stdlib monkeypatches Use the existing explicit policy IMAP/SMTP classes and canonical connect_outbound_tcp helper. Remove process-wide stdlib assignments, context-variable plumbing, redundant aliases and resolver-signature retries. Reject unsafe or unresolved hosts before account/config persistence, keep DNS work off the event loop, return fixed client errors, identify Alibaba metadata accurately and reject invalid TCP ports. Validation: 654 relevant email, URL-safety and CodeQL regression tests passed, 3 skipped. Three unrelated browser checks were excluded after environment failures (missing Playwright browser and Chromium timeout). Running-app checks verified rejected create/update/config requests leave stored data unchanged, administrator LAN configuration still works, and metadata/non-admin loopback are blocked. --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> Co-authored-by: PR #6029 Reviewer <reviewer@odysseus-review.local> Co-authored-by: Afonso Junior <chatgpt@yack.com.br> |
||
|
|
be9f575b59 |
fix(security): block read-only cookbook tools for non-admin owners (#6353)
* fix(security): block read-only cookbook tools for non-admin owners list_cached_models, list_served_models, tail_serve_output, list_downloads, search_hf_models, list_serve_presets and list_cookbook_servers were in the plan-mode read-only allowlist but in neither NON_ADMIN_BLOCKED_TOOLS nor the dispatcher's _ADMIN_TOOLS. Each implementation calls a require_admin route over the internal loopback with the process-wide INTERNAL_TOOL_TOKEN and never checks the owner, so a non-admin user's agent inherited admin reach through them. list_cached_models is the worst case: a caller-chosen `host` is forwarded to /api/model/cached, which SSHes to that host with the app user's keys and walks caller-chosen model_dirs. THREAT_MODEL.md lists model serving as admin-only, so gate the read side the same way as serve/download. Adding the names to NON_ADMIN_BLOCKED_TOOLS also hides them from non-admin tool schemas and caps bearer-token agent runs; _ADMIN_TOOLS blocks them at dispatch. Regression test covers both lists, schema hiding, and that the loopback is never reached for a non-admin owner. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TwcwfY2uQMxNRsK3y6xBAp * fix(cookbook): bind request authority in admin gate regressions Keep all seven read-only Cookbook tools in the admin prompt inventory. Grant request authority in dispatch tests so the admin gate itself is exercised, and verify administrators still reach each handler. Validation: 359 focused authorization, tool-policy and schema tests passed. Against the running app with real auth accounts, all seven tools reject a non-admin and an admin reaches the authenticated Cookbook HTTP API. --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> Co-authored-by: Afonso Junior <chatgpt@yack.com.br> |
||
|
88772b3278 |
fix(tasks): apply the admin-only action policy in manage_tasks (#6358)
POST /api/tasks and the scheduler both refuse action tasks whose action is in ADMIN_ONLY_TASK_ACTIONS (run_local, run_script, ssh_command, cookbook_serve) for owners without admin task privileges: those actions reach subprocess.run(shell=True) or SSH with no sandbox. The model-facing manage_tasks tool applied neither check, so an agent could create or edit such a task, resume it, or trigger it, and only the scheduler's execution-time guard stood in the way (pausing the task after the fact). Route the tool through the same src.task_action_policy helpers the HTTP route uses: create checks the requested type/action, edit checks the task as it would be after the edit (so an llm task cannot be flipped into a shell action), and resume/run check the stored task. Admins, non- privileged actions and llm/research tasks are unaffected; pause still works for everyone since it only narrows. Fixes #6021 Claude-Session: https://claude.ai/code/session_01UAB5sz5srMKR7rbeDFtdMH Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> Co-authored-by: Alexandre Teixeira <111787685+alteixeira20@users.noreply.github.com> |