From 84faf87ee97b7e566ceb928cbd377787d8513cf5 Mon Sep 17 00:00:00 2001 From: Nina Doschek Date: Wed, 22 Jul 2026 17:17:11 +0200 Subject: [PATCH 1/2] docs: document intended use, deployment, and security considerations - Add docs/deployment.md describing the Model Server's intended use as a local, trusted-environment development component and its trust model - Document the development-oriented defaults (all-interfaces bind, permissive CORS, no authentication) and a hardening checklist for responsible deployment - Add prominent README callouts (top matter and standalone-JAR quickstart) linking to the new document --- README.md | 6 ++++ docs/deployment.md | 72 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 78 insertions(+) create mode 100644 docs/deployment.md diff --git a/README.md b/README.md index 9704b68..8051b95 100644 --- a/README.md +++ b/README.md @@ -2,6 +2,9 @@ For more information, please visit the [EMF.cloud Website](https://www.eclipse.org/emfcloud/). If you have questions, contact us on our [discussions page](https://github.com/eclipse-emfcloud/emfcloud/discussions) and have a look at our [communication and support options](https://www.eclipse.org/emfcloud/contact/). +> [!IMPORTANT] +> The EMF.cloud Model Server is a **development-time component** intended to run **locally in a trusted environment**, driven by a trusted client. Its default configuration binds all network interfaces, enables permissive CORS, and uses **no authentication**. **Do not expose it to untrusted networks.** Before any networked or production deployment, read **[Intended Use, Deployment & Security Considerations](./docs/deployment.md)**. + ## Prerequisites The following libraries/frameworks need to be installed on your system: @@ -48,6 +51,9 @@ To run the model server standalone JAR, run this command in your terminal: cd examples/org.eclipse.emfcloud.modelserver.example/target/ java -jar org.eclipse.emfcloud.modelserver.example-X.X.X-SNAPSHOT-standalone.jar +> [!WARNING] +> This starts an **unauthenticated** server bound to **all network interfaces** with permissive CORS, suitable for **local development only**. Anyone who can reach the port can read and write models and files accessible to the server process. Do not run it on an exposed or shared host without the protections described in [Intended Use, Deployment & Security Considerations](./docs/deployment.md). + #### Usage usage: java -jar org.eclipse.emfcloud.modelserver.example-X.X.X-SNAPSHOT-standalone.jar diff --git a/docs/deployment.md b/docs/deployment.md new file mode 100644 index 0000000..e2e0db1 --- /dev/null +++ b/docs/deployment.md @@ -0,0 +1,72 @@ +# Intended Use, Deployment, and Security Considerations + +> [!IMPORTANT] +> The EMF.cloud Model Server is a **development-time building block** for creating modeling tools and applications. It is designed to run **locally, driven by a trusted client, inside a trusted environment**. It is **not** a turnkey, multi-tenant, production-hardened server, and it is **not** intended to be exposed directly to untrusted networks or clients. +> +> If you deploy it outside this intended context, **you are responsible** for adding the protections described in [Deploying responsibly](#deploying-responsibly). + +## What the Model Server is + +The Model Server is a backend **component** for building modeling tools. It exposes model access and manipulation (CRUD, commands, undo/redo, validation, change subscriptions) over HTTP and WebSocket, so that a client application (for example a [GLSP](https://eclipse.dev/glsp/)- or [Theia](https://theia-ide.org/)-based modeling tool) can be built on top of it. + +It is intended to be: + +- **embedded in or driven by a trusted client application**, typically running on the same machine or within a single controlled environment; +- operated by a **single user or a single trusted tool instance** at a time; +- used as a **framework and reference implementation** that adopters extend with their own metamodels, commands, and packaging. + +## What the Model Server is not + +It is deliberately **not**: + +- a public-facing or internet-exposed service; +- a multi-tenant or multi-user server that isolates clients from one another; +- an authentication or authorization service; +- a sandbox that defends against malicious models, payloads, or clients. + +## Security model: a trusted environment + +Like other tools designed for local use, for example [Redis, which "is designed to be accessed by trusted clients inside trusted environments"](https://redis.io/docs/latest/operate/oss_and_stack/management/security/), the Model Server assumes a **trusted client** and a **trusted workspace**, reached over a **trusted (local) network**. + +Within that trust boundary it **deliberately performs no**: + +- authentication or authorization of callers; +- network-level access control; +- sandboxing or validation of otherwise well-formed input against malicious intent; +- confinement of file access beyond the operating-system permissions of the process. + +As a consequence, and **by design**, a client that can reach the server can, among other things, read and write files that the server process is permitted to access, (re)configure the workspace location, and load and parse model content in the supported formats. These are **intended capabilities** of a local modeling backend, not security weaknesses, and they rely entirely on the deployment keeping untrusted parties *outside* the trust boundary. + +The server runs with the privileges of the operating-system user that launched it and can access whatever that user can access. + +## Development-oriented defaults + +To keep local development and browser-based tooling frictionless, the example launcher and standalone JAR: + +- **bind to all network interfaces**; +- **enable permissive CORS** (`Access-Control-Allow-Origin: *`); +- register **no authentication** on any route. + +These defaults are appropriate for **local, single-user development on a trusted machine only**. They are not safe for any deployment that is reachable by untrusted networks, browsers, or users. + +## Deploying responsibly + +If you run the Model Server in any context beyond local, trusted, single-user development, treat it as an **unauthenticated backend that must never be directly reachable by untrusted parties**, and supply the protections it does not provide itself. Recommended layers (defense in depth): + +- **Network isolation**: keep the server on a private network segment or the loopback interface, and **firewall the port** so it is not reachable from untrusted networks; never expose it to the public internet. *(The launcher currently exposes only a `-p`/`--port` option and no host-binding option, so restricting the listener to loopback requires a firewall, a reverse proxy, a container network namespace, or a customized launcher.)* +- **Reverse proxy with authentication and TLS**: place the server behind a proxy (e.g. nginx, Apache httpd, or an API gateway) that terminates TLS and enforces authentication and authorization. The Model Server performs none of these itself. +- **Restrict CORS**: do not rely on the permissive development default; restrict the allowed origins at the proxy for any networked deployment. +- **Least privilege**: run as a dedicated, unprivileged operating-system user; restrict the parts of the filesystem the process can read and write (a dedicated workspace directory, a container, or a sandbox); scope the workspace root to only the directories you intend to serve. +- **Trusted inputs only**: only load workspaces and models that you trust. Model content is parsed and file operations are performed on caller-supplied data without additional sandboxing. + +A typical hardened deployment therefore layers: *untrusted network → firewall → private network / reverse proxy → TLS → authentication & authorization → Model Server*. + +## A note on these assumptions + +This security model reflects the Model Server's intended use as a local development component. Adopters whose deployment differs should **re-evaluate** these assumptions, and it is the adopter's responsibility to add the appropriate controls before deploying outside the intended context. + +## Reporting a vulnerability + +Please report suspected vulnerabilities through the process described in [`SECURITY.md`](../SECURITY.md). Do not open public issues, pull requests, or discussions for them. + +Reports describing behavior that is only reachable when the server is deployed contrary to the guidance above (for example, exposed to untrusted networks or clients) are treated as **deployment-hardening** matters rather than defects in the component. Issues that are exploitable **within** the intended trusted-local usage are handled as described in `SECURITY.md`. From 399152a3deedae62c1527938c32a4dd0a877affa Mon Sep 17 00:00:00 2001 From: Nina Doschek Date: Wed, 22 Jul 2026 17:17:11 +0200 Subject: [PATCH 2/2] docs: update SECURITY.md to current Eclipse Foundation reporting policy - Adopt the updated Eclipse Foundation SECURITY.md template - Direct vulnerability reports to the Eclipse GitLab vulnerability tracker; email intake to security@eclipse.org is no longer accepted - Update the reporting policy link to eclipse.org/security/policy/ --- SECURITY.md | 29 ++++++++++++++++++++++++----- 1 file changed, 24 insertions(+), 5 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 6899db8..d08f187 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,8 +1,27 @@ -# Eclipse EMF.cloud Model Server Vulnerability Reporting Policy +# Security Policy -If you think or suspect that you have discovered a new security vulnerability in this project, please do not disclose it on GitHub, e.g. in an issue, a PR, or a discussion. Any such disclosure will be removed/deleted on sight, to promote orderly disclosure, as per the [Eclipse Foundation Vulnerability Reporting Policy](https://www.eclipse.org/security/policy.php). +This Eclipse Foundation Project adheres to the [Eclipse Foundation Vulnerability Reporting Policy](https://www.eclipse.org/security/policy/). -## Reporting a Vulnerability +## How To Report a Vulnerability -We recommend that in case of suspected vulnerabilities you do not use the EMF.cloud Model Server public issue tracker, but instead contact the Eclipse Security Team directly via security@eclipse.org. -Make sure to provide a concise description of the issue, a CWE, and other supporting information. +If you think you have found a vulnerability in this repository, please report it to us through coordinated disclosure. + +**Please do not report security vulnerabilities through public issues, discussions, or pull requests.** + +Instead, please create a [confidential issue](https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/new?issuable_template=new_vulnerability) in the Eclipse Foundation Vulnerability Reporting Tracker. + +You can find more information about reporting and disclosure at the [Eclipse Foundation Security page](https://www.eclipse.org/security/). + +Please include as much of the information listed below as you can to help us better understand and resolve the issue: + +* The type of issue (e.g., buffer overflow, SQL injection, or cross-site scripting) +* Affected version(s) +* Impact of the issue, including how an attacker might exploit the issue +* Step-by-step instructions to reproduce the issue +* The location of the affected source code (tag/branch/commit or direct URL) +* Full paths of source file(s) related to the manifestation of the issue +* Configuration required to reproduce the issue +* Log files that are related to this issue (if possible) +* Proof-of-concept or exploit code (if possible) + +This information will help us triage your report more quickly.