Hardening: gate monitoring-template creation and restrict script/ssh collect protocols for non-admin users

[Baymax-armed]

Background

Authoring a monitoring type via POST /api/apps/define/yml is available to the non-admin user role (/api/apps/**===post===[admin,user] in sureness.yml). A template can set protocol: script with an arbitrary scriptCommand, which ScriptCollectImpl.collect runs via new ProcessBuilder("bash","-c", scriptCommand) (hertzbeat-collector-basic/.../collect/script/ScriptCollectImpl.java:81). The import-time guard RISKY_STR_ARR (hertzbeat-manager/.../controller/AppController.java:55-59) only blocks Java/Groovy/deserialization tokens, and verifyDefineAppContent validates structure only, so a shell command passes; it can then be run synchronously via POST /api/monitor/detect.

I reported this privately to the ASF security team. They assessed it as within the documented trusted-user security model (roles are not a security boundary — "all users have management permissions"), so it is not a vulnerability, and suggested raising it here as a hardening improvement aligned with the role-enforcement work planned for 1.9.0.

Suggested hardening

• Gate POST /api/apps/define/yml to admin (matching PUT/DELETE), or under the upcoming role enforcement.
• Allowlist the collect protocol accepted in user-authored templates (exclude script/ssh/command protocols), validated at import.
• Shell-escape (or strictly allowlist) ^_^param^_^ substitutions before they enter a command.

Happy to send a PR if this direction sounds right.

[osasukev57-venn]

Hi maintainers,

I'm interested in contributing to this hardening effort. I recently submitted PR #4386 addressing the SSRF webhook validation issue (#4383), and I'd like to help with this one as well.

Before I start, I'd like to clarify the expected scope and direction:

1. Is this open to external PRs? The issue mentions aligning with the role-enforcement work planned for 1.9.0 — would you prefer contributors to wait for that, or is a standalone hardening PR welcome now?

2. Which of the three suggested hardening items should be prioritized?

   • Gate POST /api/apps/define/yml to admin-only
   • Allowlist collect protocols (exclude script/ssh/command) in user-authored templates
   • Shell-escape ^_^param^_^ substitutions

3. Should these be one combined PR or separate PRs?

I'm happy to start with the protocol allowlist validation as it seems relatively self-contained, but I'd appreciate your guidance on the preferred approach.

Thanks!