Open nichtich opened 1 year ago
Fuseki can have ACLs are various granularities - server-dataset-endpoint. This is more control than URL matching.
If you start a Fuseki default instance, the moment you create a dataset, anybody can manipulate its contents and fill your whole disk space with write operations. This is a security issue. A script to scan for IPs with open port :3030, query /$/status
and then copy and delete all database contents is three lines of shell scripting. How about changing the default ACL so new datasets are only writeable from localhost unless you actively modify the settings?
Jenkins had a similar request. I believe the user installing the tool must be responsible and enable the correct security levels that are expected, and having a simpler way to start the application for users & devs is useful.
Said that, at some point Jenkins started getting lots of security issues (like the collections serialization attacks in Java). That, combined with the number of installations everywhere from people that just started java -jar jenkins.war
, using Jenkins defaults, caused a lot of companies to have issues that started in the CI environment.
Jenkins decided then to start strengthening up it defaults, and now it asks for a user to be created, generates a unique secure password on the terminal to use, can have different groups of plug-ins installed, … but that's a lot of complexity to maintain, and running a quick test with Jenkins became quite annoying.
How about changing the default ACL so new datasets are only writeable from localhost unless you actively modify the settings?
I think @nichtich 's is a good compromise. We may get some user reports that they were not able to access Jena from 0.0.0.0
. Then we can point them to a page with instructions for enabling it, where the is also a big note saying what @afs said above, and links to how to secure Jena.
If at that point the user just enables 0.0.0.0
without worrying about securing the server, I guess at least we cannot be blamed for telling them so.
What does Jetty offer?
A solution needs to address the fact that here are many authentication and authorization tools/frameworks. Any standalone solution is only partial.
One way is to have a reverse proxy in front of the Fuseki server means that all the capabilities of that reverse proxy for authentication integration are available.
The WAR file is already in Tomcat which can provide security.
Version
4.7.0
Feature
As configured in its default shiro.ini, a Fuseki server allows read- and write-access from anywhere by default. This is a very dangerous default. I'd change this to
/$/metrics
to localhostSure this is insecure still but at least just changing the default password will restrict public write access to all your data.
Are you interested in contributing a solution yourself?
Yes