search

eclipse-oomph / oomph

Eclipse Public License 2.0
6 stars 11 forks source link

Support shared/read only install of a product #34

Open laeubi opened 1 year ago

laeubi commented 1 year ago

When I launch the installer I'm currently presented with this standard options:

grafik

as part of the Eclipse WG imitative to supporting secured installation layouts for eclipse, it was decided that the most safe way seems to install eclipse in a read-only way so probably only elevated administration user can modify the original install of eclipse (especially placing new file in the root of eclipse what might be a source of DLL Injection or replacing the eclipse.exe and similar treats.

Oompf should therefore help the user to make things more secured by the following ways

  1. If installed a product it should make sure that the folder and its files are only writable by that user for example using NIO Path API if that is not possible we might want to warn the user about this insecurity
  2. There might be an option to make the install even readonly for this purpose the product has to be started once with -initialize and then can be made readonly as described here. Even though eclipse chooses a default of <user-home-dir>/.eclipse/<product-id>_<product-version>/configuration for the private user part, this might be configurable as well for the convenience of the user.
  3. There might even be an option to create a shared install the main difference is that the product will not installed with user-right but elevated rights that make the install read only and even not modifiable by the current user account. This is the most complex because it will require integration with the native operation system way of requesting elevated permissions but thanks to FFM API even that would be solvable from java

Option 1+2 seem quite straight forward, but still have one flaw: If my user account get compromised even for a short time (e.g. forget to logout while taking a coffee) my eclipse might get compromised even though of course this opens up for much more serve security problems. Option 3 is the most complex but what one today might expect from modern installers, especially in managed environments.

I have used shared-installs (manually configured of course) in the past for supporting Windows-Terminal Server, so even beside the security aspect supporting shared-installs would be great for the users (or more their admins).

merks commented 1 year ago

Some of concerns are covered by documentation here:

https://www.eclipse.org/setups/installer/question/

E.g., one can avoid using a bundle pool or one can create shared installations even with a bundle pool running as an admin and managing the location of the bundle pool.