Add draft threat model + SECURITY.md/AGENTS.md discoverability

[potiuk]

What this is

A draft threat model for Apache Jena, proposed by the ASF Security team for the Jena PMC to review, correct, or reject — drafted by the Security team's threat-model tooling from Jena's public docs and repository, following the ASF Security threat-model rubric. It was requested by the PMC (andy@) as a starting point.

This PR:

• adds THREAT_MODEL.md — the draft model;
• adds SECURITY.md — a short security policy linking the threat model;
• adds AGENTS.md with a ## Security section, so the chain AGENTS.md → SECURITY.md → THREAT_MODEL.md is mechanically discoverable by automated security scanners.

How to read it

Every claim is provenance-tagged: (documented) (from Jena's docs/repo), (inferred) (reasoned from architecture, not yet confirmed), (maintainer) (confirmed by the PMC). This v0 is ~12 documented / ~34 inferred. The §14 Open questions section collects every inferred claim into waves — that is where review time is best spent. The model treats Fuseki's SPARQL endpoint as the primary boundary (public query, localhost-only admin by default are documented) and flags the high-value query surfaces for confirmation:

• the SPARQL Update default (read-only vs update-enabled) — decides whether anonymous write is in-model (wave 1);
• SERVICE federation (SSRF), file:/FROM local-file read, ARQ JavaScript/custom functions (code exec), and RDF/XML XXE in RIOT — is each prevented/restrictable by default? (wave 2);
• the resource/DoS line (query timeout / result limits) — addressing the PMC's volume concern (wave 3).

Nothing here is a requirement — the model is for the PMC to own. Comment inline, edit the branch, or reply on the email thread.

[rvesse]

Thanks @potiuk for the first pass at this, I think this looks like a pretty solid starting point.

I have gone through the model and made various suggested edits throughout (mostly confirming/clarifying things you'd marked as needed that). I won't commit the edits yet as I want to give the rest of the PMC chance to review the initial draft as-is

Have also provided initial answers for most of the questions. Some of those answers are just me pinging other PMC members with the relevant expertise in a particular area of the codebase to provide their input

[rvesse]

Suggested change

	- **Admin boundary:** the `/$/*` admin surface is localhost-only by default *(documented)*; exposing it to the network is an operator misconfiguration.
	- **Admin boundary:** the `/$/*` admin surface is localhost-only by default *(documented)*; exposing it to the network (without configuring authentication/authorisation) is an operator misconfiguration.

[rvesse]

Suggested change

	- **Store:** TDB1/TDB2 on the local filesystem, assumed private to the Fuseki/JVM process. *(inferred)*
	- **Store:** TDB1/TDB2 on the local filesystem, private to the owning Fuseki/JVM process, multiple processes accessing a single store location prevented by code. *(maintainer)*

[rvesse]

Suggested change

- **Negative side-effects inventory** (inferred — wave-1/2 target): Fuseki listens on HTTP; ARQ can make **outbound** network requests via `SERVICE` (federation) and can read **`file:`/http: URLs** named in queries (FROM/FROM NAMED/SERVICE); RIOT parses untrusted RDF; ARQ may execute **custom/JavaScript functions** if the operator enabled them; TDB reads/writes the data directory. *(inferred — these are the load-bearing confirmations)*

- **Negative side-effects inventory** (inferred — wave-1/2 target): Fuseki listens on HTTP; ARQ can make **outbound** network requests via `SERVICE` (federation), `SERVICE` can be disabled by operator in configuration; ARQ can read **`file:`/http: URLs** named in queries (FROM/FROM NAMED/SERVICE); RIOT parses untrusted RDF; ARQ may execute **custom/JavaScript functions** if the operator enabled them; TDB reads/writes the data directory. *(inferred — these are the load-bearing confirmations)*

[rvesse]

@afs On the point of reading file:/http URLs in queries/updates isn't that partly a feature of what dataset implementation is used i.e. is this something the operator can control/disable by choice of configuration?

[rvesse]

Suggested change

	| `SERVICE` (federated query) | **to confirm** (enabled? restrictable allow-list?) | *(inferred)* SSRF surface; whether it can be disabled / allow-listed is the key §10 lever. |
	| `SERVICE` (federated query) | may be disabled by operator config **(documented)** | *(inferred)* SSRF surface

Documentation references:

• https://jena.apache.org/documentation/query/service.html#controlling-service-requests
• https://jena.apache.org/documentation/fuseki2/fuseki-configuration.html#server-configuration

[rvesse]

Suggested change

| ARQ **JavaScript / custom functions** | **to confirm** (opt-in?) | *(inferred)* If enabled, SPARQL can execute code → by-design-if-operator-enabled, like a trusted extension. |

| ARQ **JavaScript / custom functions** | opt-in feature, requires explicit operator config of both Fuseki and JVM | *(inferred)* If enabled, SPARQL can execute code, executable JS functions controlled by explicit white list *(documented)*, some JS functions, e.g. `eval()`, are explicitly blacklisted regardless of whitelist → by-design-if-operator-enabled, like a trusted extension. Java custom functions require explicit operator configuration of class path, if added to class path operator responsibility to verify function code is safe |

[rvesse]

Documentation references:

• https://jena.apache.org/documentation/query/javascript-functions.html#requirements
• https://jena.apache.org/documentation/query/javascript-functions.html#identifying-callable-functions

[rvesse]

Yes, opt-in and explicit white list for permitted JS functions.

For custom Java functions operator has to explicitly add code to their class path so operator responsibility to verify they trust the custom function code

Code execution is by-design-operator-enabled

[rvesse]

I believe so, this is @afs's area of expertise having rewritten those parsers relatively recently

[afs]

RDF/XML - XXE is disabled (JenaXMLInput).

JSON-LD has it's own version the XXE concern.

[rvesse]

I don't think we can treat these are bugs, these are known issues in the wider RDF/SPARQL community and its operator responsibility to apply configuration (e.g. query timeout), request size limits via reverse proxy etc.

[afs]

We ought to couple with needing to enable SERVICE in Fuseki.

(the volume concern I mentioned is number of requests - it can flood a server)

[rvesse]

Yes, for in-process its app responsibility to verify untrusted inputs and apply any appropriate hardening

Parameterised queries are recommended pattern

[afs]

Fuseki itself does not have parameterised queries.

[rvesse]

Probably worth reviewing the TDB FAQs page, the following two in particular come to mind that are recurring topics on the mailing lists:

1. Does Fuseki/TDB have a memory leak? - Unbounded memory growth under continuous read/write load is a known issue and our use of a WAL ensures no data is lost should the process crash/restart due to this
2. Why is the database much large on disk than my input? - This is two-fold, firstly we use sparse files so depending on how disk usage is inspected (and the filesystem in use) different usage metrics can be reported. Secondly TDB2 uses MVCC trees so each write transaction potentially creates new blocks in the trees orphaning the old blocks (once any active read transactions on the old tree state have completed), this is expected behaviour and we provide a compaction operation that we recommend operators run periodically to reclaim disk space.

[afs]

Item 1 should be for TDB1 only.

[potiuk]

Thanks @rvesse — genuinely useful, detailed review. Understood you're holding your own commits so the rest of the PMC can review the as-is draft first, so I won't push anything over that.

For when you're ready: I've staged a revision incorporating all your suggestions — SSRF via SERVICE documented as a VALID vector (with the "no allow-list today" note), FROM/file: reworded as dataset-implementation-dependent (TDB2 restricts to dataset graphs), the "super-linear" DoS framing removed (operator-tuned, affects all compliant engines), the ARQ-JS (opt-in + eval-blacklisted) vs Java-custom-function (operator-classpath, by-design) distinction, and the TDB-FAQ resource references. It's ready to land whenever the PMC's done with the as-is draft — just say the word. (And afs@ can confirm the RDF/XML XXE-default question when convenient — that's the one item I left open.) No rush.

[arne-bdt]

I flew over the files and have nothing to add so far.

(Yesterday, I realized I am overworked since a few days and need some time off, to be able to think straight again)

[potiuk]

Thanks @arne-bdt — appreciate the look. And genuinely, take the time off you need; there's zero rush here, the draft will keep. Be well. 🙂

[afs]

JSON-LD is provided by a dependency.

There is work in the current JSON-LD W3C Working Group to document and provide mitigation for the issue that JSON-LD reads remote file.

It is safer than XML External Entities but nevertheless, it's an issue.

[afs]

Jena also provides a Lucene-based text index component including in Fuseki.
Should that be included here?

[afs]

Suggested change

	| Stores | `jena-tdb1`, `jena-tdb2`, `jena-db` | filesystem | **In (engine's use); on-disk store is operator-trusted** *(inferred)* |
	| Stores | `jena-tdb1`, `jena-tdb2`, `jena-text` | filesystem | **In (engine's use); on-disk store is operator-trusted** *(inferred)* |

jena-db is the module that provides a database framework. TDB2 uses it. TDB2 is the actual database.

TDB1 predates jena-db.

jena-text (Lucene-based) is also a persistent, read-write storage component.
Should it be listed here rather than later?

[afs]

For cokpletness, list the different parts of the SPARQL family.

Suggested change

	- **Fuseki** — a long-running **HTTP server** that answers SPARQL over the network. The primary network trust surface.
	- **Fuseki** — a long-running **HTTP server** that answers SPARQL Query and SPARQL Update as well as the SPARQL Graph Store Protocol (read and read-write forms) over the network. The primary network trust surface.

[afs]

Suggested change

	- **anonymous SPARQL client** — issues SPARQL queries over HTTP. **Default-public for query** *(documented — Fuseki security docs: "SPARQL endpoints are open to the public but administrative functions are limited to localhost")*.
	- **anonymous SPARQL client** — issues SPARQL queries over HTTP. **Default-public for SPARQL query** *(documented — Fuseki security docs: "SPARQL endpoints are open to the public but administrative functions are limited to localhost")*.

SPARQL Update and Graph Store Protocol update are not the default for TDB2 stored data.
They are default for the in-memory configuration if the server is started with no initial data.

[afs]

In default configurations, FROM / FROM NAMED are URIs used as names of graph in the dataset - already accessible data via GRAPH - even for file:

file: does not read local storage.

[afs]

RDF/XML - XXE is disabled (JenaXMLInput).

JSON-LD has it's own version the XXE concern.

[afs]

We ought to couple with needing to enable SERVICE in Fuseki.

(the volume concern I mentioned is number of requests - it can flood a server)

[afs]

Fuseki itself does not have parameterised queries.

[afs]

Item 1 should be for TDB1 only.