Yicong-Huang commented on code in PR #4299: URL: https://github.com/apache/texera/pull/4299#discussion_r3025182347
########## SECURITY.md: ########## @@ -202,23 +207,28 @@ a user needs it. Texera's security model does NOT guarantee: - Protection against malicious code in user workflows (users can execute arbitrary code) +- Isolation of application secrets from UDF code executing within the same process or pod Review Comment: I suggest remove this. This is too specific to UDF. It is already covered by bullet point 1. ########## SECURITY.md: ########## @@ -262,7 +272,7 @@ lists and website. --- -**Last Updated**: November 2025 +**Last Updated**: March 2026 Review Comment: April? ########## SECURITY.md: ########## @@ -202,23 +207,28 @@ a user needs it. Texera's security model does NOT guarantee: - Protection against malicious code in user workflows (users can execute arbitrary code) +- Isolation of application secrets from UDF code executing within the same process or pod - Strong isolation between workflows in local computing units - Complete isolation between workflows in Kubernetes computing units within the same namespace - Protection against infrastructure-level compromises - Protection against deployment manager misconfigurations - DDoS protection (requires external infrastructure) - Compliance with specific regulatory requirements without additional configuration -## What are NOT Security Issues +## What is NOT a Security Issue The following are **NOT considered security vulnerabilities** in Texera: ### User Code Execution -REGULAR and ADMIN users can execute arbitrary code (Python, R, Scala) within computing units. This is by design - Texera -is a data analytics platform where custom code execution is a core feature. The system currently does not sandbox user -code beyond the isolation provided by the deployment environment (local processes or Kubernetes pods). Deployment -managers should use resource limits, monitor usage, and restrict user roles appropriately. +REGULAR and ADMIN users can execute arbitrary code (Python, R, Java, Scala) within computing units through UDFs. This is by design — custom code execution is a core feature of the platform. + +UDF code may access resources available in the execution environment, including: Review Comment: including but not limited to ########## SECURITY.md: ########## @@ -202,23 +207,28 @@ a user needs it. Texera's security model does NOT guarantee: - Protection against malicious code in user workflows (users can execute arbitrary code) +- Isolation of application secrets from UDF code executing within the same process or pod - Strong isolation between workflows in local computing units - Complete isolation between workflows in Kubernetes computing units within the same namespace - Protection against infrastructure-level compromises - Protection against deployment manager misconfigurations - DDoS protection (requires external infrastructure) - Compliance with specific regulatory requirements without additional configuration -## What are NOT Security Issues +## What is NOT a Security Issue The following are **NOT considered security vulnerabilities** in Texera: ### User Code Execution -REGULAR and ADMIN users can execute arbitrary code (Python, R, Scala) within computing units. This is by design - Texera -is a data analytics platform where custom code execution is a core feature. The system currently does not sandbox user -code beyond the isolation provided by the deployment environment (local processes or Kubernetes pods). Deployment -managers should use resource limits, monitor usage, and restrict user roles appropriately. +REGULAR and ADMIN users can execute arbitrary code (Python, R, Java, Scala) within computing units through UDFs. This is by design — custom code execution is a core feature of the platform. + +UDF code may access resources available in the execution environment, including: + +- Texera's application configurations +- Environment variables of the host + +This is not considered a vulnerability. Deployment managers are expected to mitigate this risk by ensuring only trusted users are granted access to the platform. Users who are no longer trusted should have their roles adjusted to RESTRICTED, which disallows any workflow execution. Review Comment: I feel "What is not a security issue" already cover this. ########## SECURITY.md: ########## @@ -202,23 +207,28 @@ a user needs it. Texera's security model does NOT guarantee: - Protection against malicious code in user workflows (users can execute arbitrary code) +- Isolation of application secrets from UDF code executing within the same process or pod - Strong isolation between workflows in local computing units - Complete isolation between workflows in Kubernetes computing units within the same namespace - Protection against infrastructure-level compromises - Protection against deployment manager misconfigurations - DDoS protection (requires external infrastructure) - Compliance with specific regulatory requirements without additional configuration -## What are NOT Security Issues +## What is NOT a Security Issue Review Comment: hmm. why change to singular form? -- 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]
