This is a question asked by mobile operators moving from a constrained world (CLDC/MIDP) to a much more open one (CDC/OMEE/OSGi)... Code sharing is attractive if the system could guarantee the control of sharing and isolation mechanisms.
I wasn't aware of the new method Bundle.loadClass(). It sounds like a simple shortcut to Bundle.getClass().getClassLoader().loadClass(), isn't it ? -- André -----Message d'origine----- De : Peter Kriens [mailto:[EMAIL PROTECTED] Envoyé : jeudi 18 janvier 2007 09:28 À : BOTTARO Andre RD-MAPS-GRE Cc : felix-dev@incubator.apache.org Objet : Re: Code sharing and code isolation 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 dangerous. 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> 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> 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
