Security: Docker image or Java Sandboxing

[mfhepp]

Hi, PlantUML is great! But despite open-source, it is also a relatively large executable that will be run in many environments with broad access rights, e.g. full-disk access, network, etc. In the light of Supply Chain Attacks (e.g. dependencies become compromised by malicious code) etc., it would be good to isolate PlantUML from the host system.

There are two immediate directions:

1. Run PlantUML in a Docker container, as e.g. based on this Docker image.
2. Provide a transparent mechanism that limits the access privileges of the .jar.

I am not familiar with the complex Java Security Model, but it seems possible to provide a security permissions file and include that when invoking the JRE.

So for instance, one could limit it to reading and writing the current working directory and the stuff necessary to run the Graphviz engine.

My key point is that it should be in a transparent way, e.g. a separate permissions.txt so that it is open for quick inspection, like so:

java -Djava.security.manager -Djava.security.policy=permissions.txt -jar plantuml.jar sequenceDiagram.txt

If hidden in the source-code, it is inaccessible for inspection and requires users to "trust" the binary. Which is against state-of-the-art "minimal trust" approaches.

Requires Actions, IMO:

1. Clarify the current security model in the documentation, including dependencies and the build environment.
2. Produce a minimal policy file permissions.txt. I think this will not be a lot of effort if one knows the inner mechanics of PlantUML, but hugely contain potential risks.

Think Log4J to get a grasp of what trouble, effort, and reputation risk is at stake ;-).

[arnaudroques]

Security is a real concern for our team.
There is another aspect that you did not mention: PlantUML can be used with so many tools that it's difficult to give a simple answer.

For example, if you expose some PlantUML server on the Internet, you will have very different concerns as if you simply run locally plantuml.jar with your own diagrams (because you will then have no control about which diagrams will be generated by your users).

We have documented the security profile https://plantuml.com/security you can use when deploying PlantUML.

This page is generated from a openwiki http://alphadoc.plantuml.com/doc/markdown/en/security which accepts different syntaxes (markdown/asciidoc/dokuwiki).
This is completely open (you don't even have to create any login!)

1. Clarify the current security model in the documentation, including dependencies and the build environment.

About dependencies, situation is very simple: we use two external libraries (not even Log4J!):

• Ant for building. This is not required at runtime
• GraphViz (for some diagrams). You can remove this if you use https://plantuml.com/en/smetana02

2. Produce a minimal policy file permissions.txt. I think this will not be a lot of effort if one knows the inner mechanics of PlantUML, but hugely contain potential risks.

We probably need a collection of several permissions.txt
I let you propose a first minimal policy file with no permission at all: it should simply work for all diagrams that don't need GraphViz

[mfhepp]

Thanks a lot! I suggested making this a default in pandoc-plot in LaurentRDC/pandoc-plot#51

Will try to work on a permissions.txt or recommended set of CLIs for typical Pandoc-based workflows.

[mfhepp]

And basically, once the required paths for running PlantUML this way are clear, also the required volume settings for a Docker file are clear.

I leave this issue open for the moment in case others want to contribute to such a Docker file for PlantUML.