Hi Ok, right, subsystem is one approach.
Another, quite intrusive one, might be a class loader hook: This would allow us to filter visible classes per bundle Yet, while this would get us the java.lang.System allowed or not ? But it not get us "prevent System.exit". But it would get us "no reflection here, sorry" ;-) Regards Felix Am 14.01.2014 um 01:01 schrieb Carsten Ziegeler <[email protected]>: > I think using OSGi subsystems would bring at least some points of isolation > and control - it's clearly not designed for security but leveraging it is a > step closer to the goal. > > Carsten > > > 2014/1/14 Chetan Mehrotra <[email protected]> > >> 1a and 1b would enable us to sandbox scripts and would be quite a good >> feature to have. This would allows us to have a much better Multi >> Tennant support story. >> >> However the problem with sandboxing untrusted code in any form >> requires quite a bit of an effort. Just to start with >> >> a. Disable access to Java reflection API >> b. Limit access to OSGi service registry >> c. Limit access to JMX. You can invoke OSGi Framework API via JMX Beans! >> >> ... there would be lot more other aspects that needs to be considered. >> >> Doing this would certainly require a SecurityManager. And adding that >> after a system has evolved would require quite an effort as Ian >> mentioned. Further you always have a chance that such sandboxed >> scripts can hog system resources (endless while loop!) thus effecting >> other parts of the system. While some language like Groovy provide >> some support [1] to enable running scripts in a sandbox. Its still >> hard to say that its fully sandboxed. >> >> So even if its possible theoretically to sandbox code in JVM it would >> be too much an effort to support that. And then also there would be >> possibilities of system checks getting bypassed due to >> vulnerabilities. Hence supporting 1 or 1a, 1b, 1c in any form would >> not be possible practically. >> >>> 2. 3rd party "app bundles" >> >> I would say this falls in #1 and cannot be supported in a sure shot manner. >> >> Chetan Mehrotra >> [1] http://groovy-sandbox.kohsuke.org/ >> >> >> On Tue, Jan 14, 2014 at 3:56 AM, Alexander Klimetschek >> <[email protected]> wrote: >>> Right, good analysis! I have further important additions to #1 and #2: >>> >>> #1 of course is difficult. It should be split up: >>> ----------------------------------------------------- >>> >>> 1a. malicious JSP/script code >>> >>> Injecting a script that gets executed by Sling can be a lot easier >> (incorrect ACLs on production systems) than deploying a bundle (which >> should only possible with admin). This is definitely a goal that Sling >> should have: that you can make sure scripts can be fully sandboxed. >>> >>> There are 2 important separations: access to java APIs and - since it is >> core to Sling - access to the resources / jcr. The first should be possible >> by just whitelisting APIs a script can use (e.g. no System.exit()) while >> the latter requires a fully safe authentication mechanism that is handled >> on the jcr side. >>> >>> 1b. malicious bundles reading from JCR through the API >>> >>> Even if a bundle could be installed, IMO it is not clear that it should >> have access to the data in the resource tree (JCR). A service user mapping >> config _could_ in theory be implemented safely so that you cannot >> circumvent it through Java code (that's what I was refering to in my >> original mail). This would make the JCR safe (ignoring the issue of reading >> the repo via the file system or reloading the repo bundle). >>> >>> 1c. malicious bundles in general >>> >>> Of course, if an attacker can install bundles, he could do: >>> - malicious code: things like System.exit(), endless loops >>> - access critical infra services (OSGi admins, crypto service etc.) >>> - try to read osgi config data from the filesystem >>> - try to read the repository data directly through the filesystem (i.e. >> using a customized jackrabbit bundle without authentication) >>> >>> Ignoring how much work it would be in the end, solutions that IMO are at >> least possible: >>> - a new "OSGi sandboxing", so that they cannot import all >> packages/classes, but just a subset (e.g. no "System.*"; a simpler way than >> JaaS); to avoid permission management hell for normal product development, >> you'd only do this in production with a "seal now" button, so that >> permissions are restricted only for newly added (malicious) bundles >>> - similarly, disable file system permissions through JaaS, as a >> whitelist on a production system (configured in the filesystem and not >> through a web UI provided by Sling itself, or at least not with a >> replaceable bundle, so you couldn't hack the configuration) >>> - remember, the JCR access was protected already through safe >> authentication; no need for making the jcr packages invisible or inventing >> a JaaS permission, as JCR already has an auth mechanism >>> >>> >>> With 1b and 1c in place, even a malicious bundle could not steal >> arbitrary data from the repository (unless exposed by other services >> through an API, internally using a loginByService() with a more powerful >> user; which in most cases is wrong; note that all other code would be >> implicitly using the request session). >>> >>> If you say "it's impossible" it will be a self-fulfilling prophecy: you >> add new stuff that doesn't care about the clear boundaries, and then it is >> indeed impossible to find a way to shield things from each other. Before >> you can think about using JaaS, you have to have clear APIs and boundaries, >> so that permissions are simple and obvious and not too complex. >>> >>> >>> Also, there is an important case for #2: >>> ----------------------------------------------------- >>> >>> 2. 3rd party "app bundles" >>> >>> Running 3rd party apps on a multi-tenant Sling instance, managed by one >> organization, but apps provided by others. Here the requirement to make >> sure code cannot circumvent users listed in the sling user mapper might be >> more important. A safe mechanism would be useful here to reduce the things >> the bundle has to be tested and reviewed for. >>> >>> Also, here you maybe want deliberate sandboxing with just a few APIs >> accessible (similar to 1a with scripts). >>> >>> >>> Conclusion: >>> ------------------ >>> >>> We should definitely aim for #1a, #2 and #3. >>> >>> #1b and c should be designed for, even if we can't implement that >> mechanism right away. >>> >>> >>> BTW, Something that comes to my mind whenever I mention "sandboxing" >> above is the "Object capability model" [1], where code can only do what >> interfaces it gets access to. This is hard in a Java context which can load >> any class on the classpath by default, giving it access to everything. >> Instead of the JaaS approach, which simply acknowledges this fact, and thus >> has to add a permission concept to deny access, you could also think about >> simply disabling the importing in the first class, which should be feasible >> with a pure OSGi system. >>> >>> [1] http://en.wikipedia.org/wiki/Object-capability_model >>> >>> Cheers, >>> Alex >>> >> > > > > -- > Carsten Ziegeler > [email protected]
