felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kriens <Peter.Kri...@aQute.biz>
Subject Re: Code sharing and code isolation
Date Thu, 18 Jan 2007 08:27:42 GMT
That is a very wide question ...

I think you must reverse it, giving NO permissions to a bundle and
then adding permissions as needed. Dangerous things as having access
to the class loader or allowing Bundle.loadClass() are of course

However, isn't it better to create a special permission to call
createAlert()? It is very hard to analyze your code that no path can
enter criticalAlert from normal code calling. Having a specific
permission would solve that problem because all parties on the stack
would be checked. Sounds safer to me than hoping nobody can call your
code, and more in line with the Java security model.

Kind regards,

     Peter Kriens

BARMG> For security purposes, I would like to prevent bundles from
BARMG> using classes that belong to private packages of any bundle.

BARMG> I checked that if I have a hacking bundle (B) with the
BARMG> following code, it will be able to call a method
BARMG> (criticalAlert) on a private class (private.packages.Sample) of
BARMG> a bundle (A), i.e. a class which neither exported by A nor
BARMG> imported by B. In order to do that, B must acces the
BARMG> classloader of A, thus I suppose that B imports an exported
BARMG> package (public.packages) from A:

BARMG>         public void start(BundleContext bc) throws Exception {  
BARMG>                 //Getting an instance of an exported class from A...
BARMG>                 public.packages.Sample sample = new public.packages.Sample();
BARMG>                 //Trying to access the private class from A...
BARMG>                 ClassLoader loader =
BARMG> sample.getClass().getClassLoader();
BARMG>                 Class clazz =
BARMG> loader.loadClass("private.packages.Sample");
BARMG>                 Object o = clazz.newInstance();
BARMG>                 Method m =
BARMG> o.getClass().getMethod("criticalAlert", new Class[]{});
BARMG>                 m.invoke(o,new Object[]{});
BARMG>         }

BARMG> So, tell me if I am wrong, the OSGi solution to this bundle
BARMG> isolation issue is to use Java 2 permissions (with OSGi CPA or
BARMG> PA) to forbid the use of reflection (Class.newInstance and
BARMG> java.lang.reflect) to untrusted bundles. 

BARMG> There is also another threat (even more direct) in OSGi R4 :
BARMG> the use of Fragments. Are there other threats ?

BARMG> André

Peter Kriens                              Tel +33467542167
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599

View raw message