You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I launch the installer I'm currently presented with this standard options:
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
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
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.
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).
The text was updated successfully, but these errors were encountered:
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.
When I launch the installer I'm currently presented with this standard options:
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
-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.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).
The text was updated successfully, but these errors were encountered: