[security] assume unpack=true for plugins containing native code

[laeubi]

Currently one explicitly have to set the header Eclipse-BundleShape: dir to trigger P2 extracting the jar into a directory on installation.

As part of the IDE WG initiative for a secure installation layout the issue arises that currently Equinox has some built in support for extracting such things into the configuration area (see org.eclipse.osgi.storage.NativeCodeFinder.findLibrary(String)) what can impose a security risk as this location is writable and might be used as an attack vector if no proper user isolation is in place.

To prevent this P2 should also look for the Bundle-NativeCode header present and handle this as if Eclipse-BundleShape: dir is present. Apart from that, it also needs to scan the bundle contents for "eclipse native location variants" as in org.eclipse.osgi.internal.framework.EquinoxConfiguration.buildEclipseLibraryVariants(String, String, String, String) to trigger an exploded install as well.

I'm not sure if we should allow to disable that, but if we might look if there is an explicit Eclipse-BundleShape: jar header to disable that.

[tjwatson]

can impose a security risk as this location is writable and might be used as an attack vector if no proper user isolation is in place.

But the location p2 installs into has to be writable also. Otherwise p2 could not extract the content of the bundle to that directory.

[laeubi]

@tjwatson it depends, lets say I download eclipse, extract the zip file and make everything read-only it can still contain jars with embedded native code. Now I start my eclipse as a user and get the native code extracted into a writable location even though I made my install read only.

[tjwatson]

Auto-extracting bundles that assume they will be JARs on disk may have unintended consequences. Typically bundles that had Eclipse-BundleShape: dir did not actually have any classes in the root JAR, instead they had classes in embedded JARs on the Bundle-ClassPath. Exploding .class files onto a directory structure may have a performance impact on loading such classes vs. the JAR.

@tjwatson it depends, lets say I download eclipse, extract the zip file and make everything read-only it can still contain jars with embedded native code. Now I start my eclipse as a user and get the native code extracted into a writable location even though I made my install read only.

But then the configuration folder in the install area will be read-only then. There was some discussion in the past to trigger the framework to do all the necessary extraction of embedded content (native-code, bundle-classpath JARs) such that the configuration area can be primed after install and then set to read-only after that first lauch.

[guw]

configuration area can be primed after install and then set to read-only after that first lauch

This approach is actually a problem on MacOS. This already destroys the .app signature. It would be better if any write attempt is redirected to a user writable area. (eg. ~/Library/Application Support/Eclipse/configuration).

[laeubi]

This already destroys the .app signature. It would be better if any write attempt is redirected to a user writable area. (eg. ~/Library/Application Support/Eclipse/configuration).

well the goal is that nothing is written (and therefore after that read) to/from user modifiable directories, therefore I'd like P2 to do any useful extraction work before.