HTHou commented on PR #17823:
URL: https://github.com/apache/iotdb/pull/17823#issuecomment-4608438757
Thanks for preparing this. Speaking as an IoTDB PMC member, I think this is
a useful v0 draft and a good starting point for the PMC to own and refine. I
agree with the approach of keeping inferred claims explicit and promoting them
as the PMC confirms or corrects them.
A few points I can confirm or suggest clarifying from the current project
behavior/configuration:
1. Deployment posture: IoTDB should generally be treated as
operator-deployed infrastructure. My suggested wording is
trusted-network-by-default, with the client RPC surface as the main in-model
boundary. Direct public exposure, especially with default credentials, should
not be considered a supported production posture.
2. Default `root:root`: the default administrator account/password exists
for initial setup and local getting-started use. It should be documented as a
must-change before production use or exposure outside a trusted environment,
not as a supported production posture.
3. REST/MQTT defaults: both REST and MQTT are disabled by default in the
current config:
- `enable_rest_service=false`
- `enable_mqtt_service=false`
4. Client Thrift SSL is available but disabled by default:
- `enable_thrift_ssl=false`
5. Extension/server-side execution: `USE_UDF`, `USE_TRIGGER`, `USE_PIPE`,
and `USE_MODEL` are system privileges and are grantable privileges, not
strictly root/admin-only operations. My suggested security-model interpretation
is that principals granted these privileges are trusted for the corresponding
server-side execution capability. RBAC is the authorization boundary here, not
a sandbox.
6. Resource/DoS line: I would distinguish malformed/pre-auth/client input
causing crashes, OOMs, deadlocks, or clearly unbounded behavior from ordinary
expensive queries or write load. The former should remain in-model
security-relevant behavior; the latter is generally an operator
capacity/resource-management concern unless there is a specific bug such as
super-linear amplification, missing limits where limits are expected, or a hang.
For inter-node trust, Byzantine peer assumptions, and the exact wording of
the long-term triage policy, I think it is reasonable to keep them as explicit
open questions and settle them through follow-up PMC discussion rather than
trying to finalize the whole threat model in this PR.
So overall: I support using this PR as the initial draft, with the current
defaults and privilege model above folded into the document where appropriate.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
