Summary

This PR fixes a security-sensitive permission enforcement gap in built-in file tools. The query runner only forwarded file_path into the permission layer, while several core file tools use path, which meant configured permission.path_rules could be bypassed for those calls. In practice, that allowed blocked reads in default mode and blocked writes in full_auto; this patch normalizes the effective target path before evaluation and adds regression coverage for both cases.

Related Issue

No linked public issue. This PR addresses a local file-access boundary failure in the documented permission.path_rules control.

Changes

• Normalize permission-time file path extraction in src/openharness/engine/query.py so built-in tools using either file_path or path are evaluated consistently.
• Resolve relative paths against the session cwd before applying deny rules, so permission decisions are made against the real absolute target path.
• Add regression tests covering the two security-relevant cases from validation:
  • a blocked read_file call in default mode
  • a blocked write_file call in full_auto
• Preserve the documented behavior in README.md by making implementation and security expectations match again.

Security Context

The root cause was an argument-name mismatch in the permission boundary. PermissionChecker supports path-level rules, but the query runner only passed file_path into that layer. Several core file tools instead use path, so the real filesystem target never reached permission evaluation.

That mismatch had direct security impact:

• read_file is treated as read-only, so the bypass allowed reads from denied paths in default mode
• write_file and similar mutating tools could reach denied paths once the session was in full_auto

Steps to Reproduce

1. Check out vulnerable snapshot 7f7081b8a5f8bcd9dde26094aa470f20bd02098c.
2. From the repository root, run a local PoC with PYTHONPATH=src uv run python.
3. Configure PermissionChecker(mode=PermissionMode.DEFAULT, path_rules=[{"pattern": "/etc/*", "allow": False}]).
4. Invoke _execute_tool_call(..., "read_file", {"path": "/etc/hosts", "offset": 0, "limit": 1}).
5. Expected result: the call is denied because the path matches the configured rule.
6. Actual result on the vulnerable snapshot: the call succeeds and returns file content from /etc/hosts.
7. Configure PermissionChecker(mode=PermissionMode.FULL_AUTO, path_rules=[{"pattern": "/tmp/*", "allow": False}]).
8. Invoke _execute_tool_call(..., "write_file", {"path": "/tmp/openharness-path-rule-bypass.txt", "content": "poc"}).
9. Expected result: the call is denied because the path matches the configured rule.
10. Actual result on the vulnerable snapshot: the marker file is created successfully under /tmp/.

Security Impact

• Confidentiality: attacker-influenced tool use can read arbitrary local text files outside the intended repository boundary, including configuration, secrets, shell history, SSH material, or adjacent credentials available to the runtime user.
• Integrity: denied host paths can be created or overwritten in full_auto, allowing tampering with local project state or other writable host files outside the intended repository scope.
• Availability: overwrite-based disruption is possible, but this is not the primary effect.

CVSS / CWE

• Severity: High
• CVSS v3.1: 7.8
• Vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:L
• CWE: CWE-284: Improper Access Control

Testing

• uv run --extra dev ruff check src/openharness/engine/query.py tests/test_engine/test_query_engine.py
• PYTHONPATH=src uv run --extra dev pytest tests/test_engine/test_query_engine.py tests/test_permissions/test_checker.py
• Full project test suite was not run for this targeted fix.

Type of Change

• Code change for a new feature, bug fix, or refactor.
• Code change with doc updates.
• Doc only. Prose changes without code sample modifications.
• Doc only. Includes code sample changes.

Checklist

General

• The summary and change list match the actual diff.
• No secrets, API keys, or credentials were committed.

Code Changes

• Tests were added for the changed behavior.
• The fix is limited to permission enforcement and regression coverage.
• The documented permission.path_rules behavior now matches the implementation for these built-in file-tool inputs.

Doc Changes

• No user-facing doc changes were needed because the intended behavior was already documented.
• SECURITY.md is still missing and should be added in a follow-up by maintainers.

Maintainer Note

The repository does not appear to publish a SECURITY.md file or another documented private disclosure path today. Adding SECURITY.md with a reporting contact or policy would make future security reports easier to handle privately.

Signed-off-by: 13ernkastel LennonCMJ@live.com