On 13.01.2014, at 21:15, Chetan Mehrotra <[email protected]> wrote:
> 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! That's all covered if you restrict package imports. A sandbox for a 3rd party plugin could look like this in form of a whitelist: allow java.lang.*; allow java.util.*; allow java.text.*; allow org.apache.sling.api.somefeature.*; Java reflection permission would be disabled. The only problem would be if packages are too fine granular, and a bundle should be able to access class com.foo.A but not com.foo.B. Getting there is probably quite some work, but it should not be impossible. > 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. Yes, but it's a difference if an attacker can steal/inject/manipulate data or whether he stops the system, thereby drawing a lot of attention to the attack. > And then also there would be > possibilities of system checks getting bypassed due to > vulnerabilities. Well, with this argument you could never build any security system :) >> 2. 3rd party "app bundles" > > I would say this falls in #1 and cannot be supported in a sure shot manner. Yes it overlaps both with 1 (malicios code) and 2 (programmer misuses). Cheers, Alex
