This is an automated email from the ASF dual-hosted git repository.
srowen pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/spark-website.git
The following commit(s) were added to refs/heads/asf-site by this push:
new 42909c2804 Add note about security model
42909c2804 is described below
commit 42909c2804700ec4476769b26c69141281a72d9c
Author: Sean Owen <sro...@gmail.com>
AuthorDate: Mon Apr 7 15:07:32 2025 -0500
Add note about security model
In response to suggestion on security list, and lightly adapted from
Flink's similar statement.
Author: Sean Owen <sro...@gmail.com>
Closes #602 from srowen/security_msg_flink.
---
security.md | 20 ++++++++++++++++++++
site/security.html | 20 ++++++++++++++++++++
2 files changed, 40 insertions(+)
diff --git a/security.md b/security.md
index cda45f0566..919b1246d8 100644
--- a/security.md
+++ b/security.md
@@ -16,6 +16,26 @@ responded.
To report a possible security vulnerability, please email
`secur...@spark.apache.org`. This is a
non-public list that will reach the Apache Security team, as well as the Spark
PMC.
+<h2>Frequently Asked Questions</h2>
+
+<h3>During a security analysis of Apache Spark, I noticed that Spark allows
for remote code execution, is this an issue?</h3>
+
+No, this is not considered an issue or a vulnerability in itself, because
remote code execution is fundamental
+to Apache Spark's design and purpose. Users can submit code in Spark jobs,
+which will be executed unconditionally, without any attempts to limit what
code can run. Starting other processes,
+establishing network connections or accessing and modifying local files are
possible. Anyone able to use a Spark
+cluster generally already has total control over the resources assigned to
their Spark application by the resource
+manager (YARN, Kubernetes, etc.).
+
+Historically, we’ve received numerous code execution vulnerability reports,
which we have rejected, as this is by design.
+Full access to the provisioned application resources is expected; it is _not_
expected that a user application can
+affect resources outside of their provisioned resources from the resource
manager, however.
+
+We strongly discourage exposing Spark clusters (including UIs and submission
endpoints) directly to the public
+internet or untrusted networks. We recommend access within trusted networks
(company intranets,
+private cloud environments), using restrict access to the Spark cluster with
robust authentication,
+authorization, and network controls.
+
<h2>Known security issues</h2>
<h3 id="CVE-2023-32007">CVE-2023-32007: Apache Spark shell command injection
vulnerability via Spark UI</h3>
diff --git a/site/security.html b/site/security.html
index 30f08b53e9..69a98525c9 100644
--- a/site/security.html
+++ b/site/security.html
@@ -162,6 +162,26 @@ responded.</p>
<p>To report a possible security vulnerability, please email <code
class="language-plaintext highlighter-rouge">secur...@spark.apache.org</code>.
This is a
non-public list that will reach the Apache Security team, as well as the Spark
PMC.</p>
+<h2>Frequently Asked Questions</h2>
+
+<h3>During a security analysis of Apache Spark, I noticed that Spark allows
for remote code execution, is this an issue?</h3>
+
+<p>No, this is not considered an issue or a vulnerability in itself, because
remote code execution is fundamental
+to Apache Spark’s design and purpose. Users can submit code in Spark
jobs,
+which will be executed unconditionally, without any attempts to limit what
code can run. Starting other processes,
+establishing network connections or accessing and modifying local files are
possible. Anyone able to use a Spark
+cluster generally already has total control over the resources assigned to
their Spark application by the resource
+manager (YARN, Kubernetes, etc.).</p>
+
+<p>Historically, we’ve received numerous code execution vulnerability reports,
which we have rejected, as this is by design.
+Full access to the provisioned application resources is expected; it is
<em>not</em> expected that a user application can
+affect resources outside of their provisioned resources from the resource
manager, however.</p>
+
+<p>We strongly discourage exposing Spark clusters (including UIs and
submission endpoints) directly to the public
+internet or untrusted networks. We recommend access within trusted networks
(company intranets,
+private cloud environments), using restrict access to the Spark cluster with
robust authentication,
+authorization, and network controls.</p>
+
<h2>Known security issues</h2>
<h3 id="CVE-2023-32007">CVE-2023-32007: Apache Spark shell command injection
vulnerability via Spark UI</h3>
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@spark.apache.org
For additional commands, e-mail: commits-h...@spark.apache.org
