Copilot commented on code in PR #5275:
URL: https://github.com/apache/zeppelin/pull/5275#discussion_r3456825850
##########
THREAT_MODEL.md:
##########
@@ -147,20 +151,20 @@ value**, so the model is ambiguous until the PMC rules on
each (see §14 wave 1)
| Knob | Default | Effect on model | Maintainer stance |
| --- | --- | --- | --- |
-| Shiro authentication (`conf/shiro.ini`) | **absent → anonymous**
*(documented)* | No auth boundary at all; every §8 authn/authz property is void
| **?** supported posture vs dev-only — §14.1 |
-| `zeppelin.notebook.public` / `ZEPPELIN_NOTEBOOK_PUBLIC` | **`true` → new
notes public** *(documented)* | Empty-ACL note is readable/runnable by any
authenticated (or anonymous) user | **?** §14.2 |
-| Interpreter user impersonation | **off → runs as server OS user**
*(documented)* | Without it, every run-capable user's code shares the
*server's* OS identity/privileges and filesystem | **?** §14.3 |
-| Interpreter binding mode (shared / scoped / isolated) | **shared**
*(inferred)* | Process-level separation between users/notes; "isolated" is a
*stability/resource* boundary, **not** a security sandbox | **?** §14.4 |
-| URL ACLs (`[urls]` in shiro.ini) gating `/interpreter`, `/credential`,
`/configurations` | **not restricted unless operator adds them** *(documented)*
| Sensitive admin endpoints open to any authenticated role absent explicit
`[urls]` rules | **?** §14.5 |
-| HTTPS / security headers (`http_security_headers`) | **off/plain unless
configured** *(documented)* | Credentials + session over plaintext; missing
CSP/XFO | operator responsibility (§10) |
-
-**Insecure-default ruling needed.** For each row whose default is the less-
-secure value, the PMC must rule: is the default the *supported production
-posture* (→ a report against it is `VALID`), or a *dev-convenience operators
-must change* (→ `OUT-OF-MODEL: non-default-build`, and the requirement moves to
-§10)? The public docs lean toward the latter ("strongly recommended… or only
-deploy… in a secured and trusted environment"), but this needs an explicit PMC
-call because it reshapes §8/§10/§11a/§13 at once.
+| Shiro authentication (`conf/shiro.ini`) | **absent → anonymous**
*(documented)* | No auth boundary at all; every §8 authn/authz property is void
| **dev-convenience** *(maintainer — §14.1)*: anonymous is *not* the supported
posture; reports against an exposed anonymous instance are `OUT-OF-MODEL:
non-default-build` |
+| `zeppelin.notebook.public` / `ZEPPELIN_NOTEBOOK_PUBLIC` | **`true` → new
notes public** *(documented)* | Empty-ACL note is readable/runnable by any
authenticated (or anonymous) user | **by-design** *(maintainer — §14.2)*:
public-by-default is intended; an empty-ACL note being readable/runnable is not
a bug |
+| Interpreter user impersonation | **off → runs as server OS user**
*(documented)* | Without it, every run-capable user's code shares the
*server's* OS identity/privileges and filesystem | **by-design** *(maintainer —
§14.3)*: running as the server OS user is the documented default; OS isolation
requires enabling impersonation |
+| Interpreter binding mode (shared / scoped / isolated) | **shared**
*(maintainer — §14.4)* | Process-level separation between users/notes;
"isolated" is a *stability/resource* boundary, **not** a security sandbox |
**maintainer — §14.4**: default is `shared`; no binding mode is a security
sandbox |
+| URL ACLs (`[urls]` in shiro.ini) gating `/interpreter`, `/credential`,
`/configurations` | **not restricted unless operator adds them** *(documented)*
| Sensitive admin endpoints open to any authenticated role absent explicit
`[urls]` rules | **maintainer — §14.5**: no built-in admin gate; protection
relies entirely on `shiro.ini [urls]` |
+| HTTPS / security headers (`http_security_headers`) | **off/plain unless
configured** *(documented)* | Credentials + session over plaintext; missing
CSP/XFO | operator responsibility (§10); no CSP and Origin-based CSRF only —
`VALID-HARDENING` *(maintainer — §14.10)* |
+
+**Insecure-default ruling (recorded).** The PMC has ruled that every insecure
+§5a default above is a *dev-convenience / by-design* choice, not the supported
+production posture: Zeppelin's stance is "open by default, secure by
+configuration" (enable Shiro, or deploy only in a secured/trusted network). A
+report that only manifests under one of these defaults is therefore
+`OUT-OF-MODEL: non-default-build` (or `BY-DESIGN`), with the requirement living
+in §10. See §14 wave 1 for the per-knob answers.
Review Comment:
The recorded "insecure-default ruling" paragraph currently implies *every*
§5a less-secure default is not a supported production posture and that reports
should be routed to `OUT-OF-MODEL: non-default-build`. That conflicts with the
per-knob answers just above (e.g., public-by-default and impersonation-off are
marked *by-design* rather than dev-only). Consider rewording this paragraph to
distinguish the anonymous/internet-exposed posture from other by-design
defaults.
##########
THREAT_MODEL.md:
##########
@@ -250,17 +257,18 @@ publish them as committed "properties".)*
each user/note a separate interpreter *process* for stability and resource
separation; it does **not** confine what the code in that process can do to
the host or to shared backends, and absent impersonation all those processes
- still run as the **same server OS user**. *(inferred — §14.4)*
+ still run as the **same server OS user**. *(maintainer — §14.4)*
- **Notebook permissions are an application-layer ACL, not OS isolation.** A
user denied *read* on a note in the UI may still reach data through an
interpreter they *can* run if backends aren't separately access-controlled.
- *(inferred — §14)*
+ *(maintainer)*
**Well-known attack classes left to the operator/integrator:** SSRF from
interpreter code reaching internal services; secrets-in-notebooks; XSS/CSRF on
-the notebook web UI (mitigated only if `http_security_headers` + CSRF defenses
-are enabled — confirm coverage in §14); websocket cross-origin. One line each;
-the point is to put integrators on notice.
+the notebook web UI — *(maintainer — §14.10)* there is **no Content-Security-
+Policy** and CSRF protection is **Origin-header-based only**, so strengthening
+these (CSP, stronger CSRF) is welcome `VALID-HARDENING`; websocket
cross-origin.
+The point is to put integrators on notice.
Review Comment:
This sentence ends with the fragment "websocket cross-origin." which reads
like an incomplete item in the list of attack classes. Making it a complete
noun phrase would improve clarity for triage/scanner readers.
##########
THREAT_MODEL.md:
##########
@@ -334,47 +342,66 @@ The highest-leverage section for keeping scan output
signal-heavy:
## §14 Open questions for the maintainers
Review Comment:
§14 now records the PMC answers inline, so the section is no longer "Open
questions". Renaming the heading would avoid implying the questions are still
unresolved.
--
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]
