0

Did anybody run Apache Sling with an enabled Java SecurityManager? That'd need a special java.policy file to allow the actions done by all deployed bundles, and it'd be extremely helpful to have a basic version that already allows what's needed by the bundles provided with the basic Sling Starter, and to which one could add policies for additional deployed code.

I'd also be interested if someone can tell that employing the SecurityManager is infeasible in a Sling setting, perhaps due to its design properties (such as the ability to add JSPs to the JCR at runtime).

Background: If you run code of several mandants on one server, that might be neccessary to separate their code from each other. While OSGI does have some mechanisms to separate bundles from each other, it'd be trivial for malicious code to use e.g. Java reflection to grab internal stuff from services provided by other bundles. An enabled security manager might at least make that much more difficult.

(I do realize that even with a security manager it's probably quite possible for malicious code to use bugs and design flaws to get access to resources of other users on the system, and that probably the only way to seriously separate code from different mandants would be using different servers. But at least one can try to make it hard.)

Dr. Hans-Peter Störr
  • 25,298
  • 30
  • 102
  • 139
  • i can't answer your primary question. however, i can say (with reasonable confidence) that a SecurityManager will not really help you if you are intending it to protect you from malicious code in a multi-tenant jvm. a SecurityManager can protect you from malicious code executing _code_ which it should not, however it does almost nothing to protect _data_. you can certainly hide some privileged secrets behind code barriers, but in a multitenant scenario it would be next to impossible to isolate all per tenant data. – jtahlborn Aug 26 '20 at 16:05
  • @jtahlborn I do admit I don't have a particularily good feeling about that, but in the case of Sling the tenant data is put into a Java Content Repository, which has access control. Every user has his own session and can only access his own tenants data through it's API. So if one could prevent the users code to stomp around in its internals via reflection, he should in theory not be able to access other users stuff. – Dr. Hans-Peter Störr Aug 26 '20 at 16:24
  • how does the SecurityManager stop custom code from accessing other content repositories? presumably there is a root object somewhere from which these repositories are found. why would any sort of reflection be necessary to access these repositories? unless all of those common objects are protected by SecurityManager "check access" calls which restrict callers to privileged code only? – jtahlborn Aug 26 '20 at 20:27
  • (i'll admit that i don't know anything about Java Content Repository, so maybe that somehow protects things?) – jtahlborn Aug 26 '20 at 20:35
  • the gist of the problem is that _most_ java code is not written to try to protect from malicious code in the same jvm. so any data structure in the general code which may happen to reference some tenant data and has an exposed accessor is a security leak. you would need to audit _every_ framework/library that touches tenant data to ensure that it doesn't accidentally provide an access path to the data. – jtahlborn Aug 26 '20 at 20:43
  • the SecurityManager was really designed to protect "privileged" data/code from unprivileged code. you are trying to protect unprivileged data from _other_ unprivileged data, which is a very different problem. – jtahlborn Aug 26 '20 at 20:43
  • @jtahlborn Not quite. The point is that this root object is not accessible through the public API - it's hidden in the implementation. The API is structured so that all accesses verify that the session has the rights to access the data, on all accessors etc. If you can use the SecurityManager to restrict access to the API only and exclude sneaking in by accessing protected fields / methods via reflection, there really is no way to access other's data. Think of it like a database - that also separates users. – Dr. Hans-Peter Störr Aug 27 '20 at 07:54
  • right, the vulnerability is presumably not the repository (database) itself, it is in all the code _outside_ of the repository (when the data is retrieved). if any of _that_ code is holding tenant data in an accessible way, then the data can be leaked. that's what i meant by "all the frameworks/libraries". e.g. an xml processing library which has a cache of recently seen String values to reduce memory usage. – jtahlborn Aug 27 '20 at 15:30

0 Answers0