[platform-update-dev] Re: Update Manager Installs - Forcing the Use of

[Mel Martinez <melm@xxxxxxxxxx>]

> From: Dorian Birsan <birsan@xxxxxxxxxx>
> Date: Thu, 22 Apr 2004 14:38:52 -0400
>
> I also have a reservation with features specifying absolute paths. It has

> to do with potential security loopholes.
>
> Currently, eclipse itself, and update manager in particular, don't have a

> good security story. For example, custom install handlers can execute
from
> a downloaded, unsigned feature, so it is not very safe.
> Allowing features to be automatically installed to arbitrary paths (how
> many people click on each feature in the target page to see where it is
> going?) will introduce more security hazards. Once silent installs are
> supported there will be more issues (absolute install paths is just one
of
> them).
>
> I like your idea of having an update manager preference
> default.install.path that can be customized by users, but features should

> not be able to change it. Well, properly behaving custom install handler
> could do that.
>

Again, I ask you to identify the 'potential security loopholes'.

The security holes that the Eclipse Platform and Update Manager currently
introduce have nothing to do with the physical location on disk of
installed features & plugins.   As things sit right now, a plugin could
very cozily be nestled into the Eclipse directory structure and still cause
unspeakable damage.

Since, as you point out, an install handler could always place files
whereever it darn well pleases, how does putting this artificial bound on
the default.install.path protect anything?

The fact is, the job of protecting the file system from things being
written to where they should not falls on the shoulders of proper access
controls.  There are two places you can apply that. First at the OS level
one can restrict the write access of the owner of the eclipse process that
is doing the update.   Second, at the JRE level one can run with a Security
Manager and, again, restrict the write access of the code that is doing the
install.

> From: Peter Manahan <manahan@xxxxxxxxxx>
> Date: Thu, 22 Apr 2004 16:56:43 -0400
>
> My issue is more a product issue not a technical one. From a product
> prespective there are certain *rules/guidelines* that need to be followed

> to ensure products is supportable, serviceable and continues to run. Not
> following these rules breaks products increases support costs etc.
>
> 1) The user determines where products are installed
> 2) Products don't install into each other directories. That is dangerous
> for both the existing installed product and the one about to be
installed.
> If the user tries to do the install of one product into another products
> install directory the install should balk and give an error.
> 3) Products *own* their install directories and any configuration
> directories that it needs. These are all in predefined OS locations or
set
> by the user post-install.
>

Hmm... that is a nice set of rules. And they came from _where_?  I submit
that they don't apply in a very broad set of situations unless we start to
define terms very broadly.

One of my areas of concern is in-house corporate (enterprise)
installations.  The 'user' who determines where products are installed is
not necessarily the end user.  The 'user' is the admin who has 20,000
end-users that he/she wants to push a particular product out to.  The admin
wants them all to be installed in the same path for serviceability reasons.

If products don't install into each other's directories, then ACME Widgets
is reasonable for not wanting to install into an Eclipse directory tree.
Or more specifically, it is not so much that it doesn't want to do that,
but rather that it explicitely WANTS to install into its OWN directory
tree.

Software products don't *own* anything, but I understand and agree with
your sentiment.  I just don't see how that or the other two rules lead to
the restriction you are advocating.

Consider an example where ACME Widgets provides eclipse views into services
provided by another ACME Services product and is dependent on those being
present on system.  The ACME Services App is completely standalone.   The
Widgets may get installed with the Services during native install (as an
option, perhaps, or via secondary install).  Or they may get provisioned
through Eclipse Update Manager.  In the former, they might get installed,
for example, into C:\Program Files\ACME\Widgets, right next to C:\Program
Files\ACME\Services.   In the latter, I advocate that it should be
possible, and is indeed preferable, that they get installed in the exact
same place (assuming the install process has write privilege to that path,
of course).

>
> I don't have a problem with a default.install.path setting in eclipse. I
> have a problem with a default.install.path that can be set by a feature
to
> install into a location that isn't owned by eclipse. Eclipse doesn't own
> c:\Program Files\ that is owned by the OS and the way to install into
> there is to use a native installer.
> <installedir>\eclipse\ is owned by eclipse so it update manager can
> install into that as that is eclipse's "installer".
>

I guess this is where we disagree.  You seem to think of features that are
installed by the update manager as not being products themselves
independent of eclipse.  I definitely disagree with that generalization.

> If your product wants to allow this that's your products choice. But it
> shouldn't be part of the core eclipse.
>
> If eclipse ever adds a default.install.path to features which allows
> absolute paths they'll need to add a way to disable it as well. Probably
> as part of the "policy" settings. All the products that we ship for
> example would have to turn it off.
>

Then run with a security manager or file system access controls to disable
the ability of the install process to write to locations you don't want it
to.  That is the _correct_ way to protect the file system.


> >
> > If I download and install ACME Widget Feature, it is not unreasonable
> that
> > either ACME or myself might not want it installed underneath the
> umbrella
> > of a particular eclipse install directory.
> >
>
> The ACME Widget company should *not* ever *install* itself anywhere
> without user interaction.
> >
>
> Update Manager's domain is eclipse not the operating system it is
eclipse.
> It needs to stick to that.
>

Where do you make up these rules?  How do you possibly hope to enforce them
without using real access control?

The counter statement is that the Update Manager's domain does not include
file system access control.  Its domain is the download and install of
features to the platform.   Leave protecting the file system to the right
systems.