Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Trust was Re: [equinox-dev] New Update Manager UI : Your thoughts

I admit that when 'trust' comes up that my mind jumps straight to a crypto-based solution, and that same leap may or may not hold for everyone. To clarify, in my mind there are at least two places where crypto comes into play:

1. In deciding what update sites you trust

- Optimally, this is a cryptographically secure decision based on the certificate presented by the server during an SSL connection. This validates where the content comes from, protecting against DNS exploits and other man-in-the-middle attacks. In an enterprise scenario, it makes sense to apply policy to this decision, and ensure that this client policy is secured and can be securely updated by an administrative process of some sort.

2. In deciding what code you trust

- This validates the code that is to be installed on the system, which is then used in deciding what the code is allowed to do. This protects against code from untrusted repositories, and from compromised code on trusted repositories. Again, it's important that this policy be secured and administrable.

It could be argued that the second option obviates the first, but I'm a fan of flexible security solutions that allow sites to trade security for performance. This includes considering a simpler 'load-time' signature check for bundles on the path to enabling the full granular Java permission model.

I've never considered automating license acceptance based on signature, but it could make sense. I'm not familiar with the process around update and the presentation of a feature's license. Is the license present in the feature Jar, and thus potentially under a Jar signature? That would be useful when designing an interaction.

Little bit of a ramble, but hopefully illuminates where I think security intersects with this discussion. Thoughts?

-matt

-----------------------------------
Matt Flaherty
Project Lead/Architect
Notes Client Security
IBM/Lotus

equinox-dev-bounces@xxxxxxxxxxx wrote on 06/14/2007 10:07:41 AM:

>
> I can't agree more with the separation of mechanisms and policies. However
> in this particular case I don't think we are far enough along in the
> discussion / problem understanding to just say "leave this to directors".
> >From the discussion I feel that a notion of "trust" may be something
> profound and ubiquitous to the whole agent. Therefore I would like to
> understand more what people mean / want to not miss a mechanism (currently
> I think that the "trust" flag would be the mechanism and the policies would
> be how this flag is being set).
>
> So far a trusted sites could have the following implications:
> - "trust" site for licenses
> - "trust" site to automatically install updates
> - "trust" site to add other sites
> - always prefer downloading bytes from "trusted" artifact repos
> Is there any other priviledge to be a "trusted" site?
> Are we using "trust" as a kind of security mechanism? Which kind of
> security?
>
> Also given that in the new story, metadata and artifact may be two
> different machines (for example I can get the metadata for europa from the
> foundation, but get the bytes from a mirror). What does trust apply to?
> Note that I have opened bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=192678 to keep track of the
> need to remember about already accepted licenses.
>
> PaScaL
>
>
>
>                                                                            
>              Peter                                                        
>              Manahan/Toronto/I                                            
>              BM@IBMCA                                                   To
>              Sent by:                  Equinox development mailing list    
>              equinox-dev-bounc         <equinox-dev@xxxxxxxxxxx>          
>              es@xxxxxxxxxxx                                             cc
>                                                                            
>                                                                    Subject
>              06/13/2007 02:57          Re: [equinox-dev] New Update        
>              PM                        Manager UI : Your thoughts          
>                                                                            
>                                                                            
>              Please respond to                                            
>                   Equinox                                                  
>                 development                                                
>                mailing list                                                
>              <equinox-dev@ecli                                            
>                  pse.org>                                                  
>                                                                            
>                                                                            
>
>
>
>
>
> I think we are mixing up two aspects of the provisioning work. The
> mechanisms for actually performing the provisioning (doing the real work)
> and the mechanisms for defining policy around provisioning (i.e. when and
> what to provision).  Since as far as I know the provisioning work is
> supposed define a pluggable "director" aka the policy decider,  there can
> be multiple implementations of policy makes. Some implementations may
> decide to enforce a strict license check and some can decide not to.  I
> fully expect to have to roll my own director rather than use the default
> equinox implementation of it. There are probably too many different use
> cases  to try and roll a single implementation that covers them all.
>
> The original thought  behind all this was a new Update Manager UI.  In the
> original thread I made this comment
> "So it would be useful to understand/define the intended role of  the new
> update manager UI as well before going down the same path it went
> previously"
>
> The role of the Update Manager UI on the new provisioning code obviously
> hasn't been defined. What policies will new Update Manager implement?  I'd
> suggest that it should start with the requirements needed by eclipse.org to
> provision eclipse.org content like Europa etc.
>
> Peter
>
> equinox-dev-bounces@xxxxxxxxxxx wrote on 06/13/2007 02:28:26 PM:
>
> > OK, lets step back and look at it differently.
> >
> > I don?t think this would be illegal, but I am not a lawyer, and I
> > don?t play one on TV.
> >
> > Infor (the company writing the software) is using equinox server-
> > side to assemble an ERP system at WidgetCo, the company that
> > manufactures widgets.
> >
> > This is not an eclipse IDE of any kind.
> >
> > WidgetCo and Infor have a licensing agreement between them. WidgetCo
> > has purchased a license for Infor?s software and can receive free
> > updates for 1 year from the purchase date. Now, instead of
> > automatically accepting license agreements, we have a more complex
> > requirement, but a real one that needs a solution.
> >
> > Possible options:
> >
> > 1. There are update sites that are always trusted by the update
> > manager. The user that sets the ?I trust this update site? flag must
> > have in essence agreed to the license in advance. Such as free
> > updates for a year as per a license agreement. In this case, Infor
> > will stop populating the WidgetCo update site with new versions
> > after a certain date, and the onus is on Infor to make this happen.
> > Probably by getting a new license agreement signed. Very little
> > needs to be done in the update manager in this case, except to trust
> > sites that are marked as trusted. Notes could be added as to why it
> > is trusted, perhaps.
> >
> > 2. The update sites in the update manager could have attached
> > multiple license keys. These keys are transmitted to the update site
> > with the update request. Now the update site is not a simple set of
> > web pages and resources served by a apache. It needs to be a web
> > application that can validate the license keys. The update site
> > either sends the updates or rejects the request.
> >
> > 3. The update site provided by Infor could be behind a password
> > protected URL. Access to this URL is only given to customers that
> > have a signed license agreement. The license requirements are all
> > handled outside of the scope of the update manager. The the update
> > manager, the update site is marked as trusted.
> >
> > 4. Infor provides a password protected URL from which WidgetCo can
> > download an update site that WidgetCo can host locally. Again, Infor
> > and WidgetCo have the license agreement managed outside of the scope
> > of the update manager. This downloaded and hosted update site is
> > marked as trusted.
> >
> > In all cases, the marking of an update site as trusted means that
> > all license management is being handled outside of the update
> > manager. And the act of marking an update site as trusted means that
> > the administrator has agreed that all licenses required at that site
> > are already handled outside of update manager.
> >
> > An update site should have the ability to override this and say:
> > ?Never allow update manager to trust me?. This could even be the default.
> >
> > Without introducing a full blown license management system, we
> > cannot get too complex in the requirements here. But server-side
> > implementations will require the ability to trust some update sites
> > and not need license agreements individually agreed to. If only
> > because sometimes there will be no human and no UI present when the
> > update happens.
> >
> > -Don
> >
> >
> > Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307 |
> > mobile: 416-543-1085 | don.laidlaw@xxxxxxxxx
> >
> > On 6/13/07 11:56 AM, "Brett Wooldridge" <bwooldridge@xxxxxxxxxxxxxx>
> wrote:
>
> > I think there are legal ramifications, at least in the United States
> > for that.  While we?re all annoyed by licenses, I don?t think you
> > can ?auto-dismiss them? any more than you can stamp your car loan
> > with your signature.
> >
> > -Brett
> >
> > On 6/13/07 8:59 AM, "Laidlaw, Don" <don.laidlaw@xxxxxxxxx> wrote:
>
> >
> > True, but it can also be a policy of a plugin consumer to accept the
> > licenses of trusted update sites. Then the consumer only has to
> > determine which update sites will always be trusted.
> >
> > In using equinox on the server side, the update sites will usually
> > be in the same company.
> >
> > -Don
> >
> > Don Laidlaw | Sr. Research Engineer | Infor | office: 905-305-7307 |
> > mobile: 416-543-1085 | don.laidlaw@xxxxxxxxx
> >
> > On 6/13/07 9:55 AM, "Peter Manahan" <manahan@xxxxxxxxxx> wrote:
>
> >
> > The need for license acceptance is  typically a requirement
> > discretion of the plugin provider and not the consumer of the
> > plugins. So allowing the consumer to disable the license acceptance
> > should only be optional at the discretion of the plugin provider.
> >
> > Peter
> >
> > equinox-dev-bounces@xxxxxxxxxxx wrote on 06/13/2007 09:04:39 AM:
> >
> > >
> > > The provisioning system should already know about the sites and
> > > should be able to discover more.
> > >
> > > Actually I missed in there where the users said which plugin they
> wanted.
> > >
> > > User should not have to accept a license if the plugin is coming
> > > from a known/trusted site.  Sites should be ranked in this way
> > >
> > > Restart may not be needed
> > >
> > > Jeff
> > >
> > >
> >
> > >
> > > "Prashant Deva" <prashant.deva@xxxxxxxxx>
> > > Sent by: equinox-dev-bounces@xxxxxxxxxxx
> > > 06/12/2007 08:26 PM
> > >
> > > Please respond to
> > > Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
> > >
> > > To
> > >
> > > "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
> > >
> > > cc
> > >
> > > Subject
> > >
> > > Re: [equinox-dev] New Update Manager UI : Your thoughts
> > >
> > >
> > >
> > >
> > > Ok, here is some thoughts on the gui for installing a new plugin.
> > > This is in keeping with the philosophy of keeping the simple things
> simple.
> > > I wish there were a place where I could upload some docs and sample
> > > images to make the point more clear, but i will just type some
> > stufffor now.
> > >
> > > 1.        User clicks on 'Install new plugin' button
> > > 2.        Dialog box with single text field asks to enter the url of
> > > pluign update site.
> > > 3.        update manager automatically gets the latest available
> > > version of the plugin.
> > > 4.        asks the user to accept the license.
> > > 5.        if license accepted, then installs plugin and asks user
> > torestart.
> > >
> > > The update site url, etc are automatically saved by the program and
> > > user doesnt need to give a 'name' along with the url as we have to do
> now.
> > > Also no dialog box for confirming 'install all'. All user has to
> > > enter is the url and accept the license.
> > >
> > > the dialog in step 2 can have an 'advanced' button, which when
> > > selected allows user to choose the exact version to install.
> > >
> > > your thoughts? any compulsory steps in the install process we might
> > > be missing this way?
> > >
> > > prashant_______________________________________________
> > > equinox-dev mailing list
> > > equinox-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> > > _______________________________________________
> > > equinox-dev mailing list
> > > equinox-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> >
> > _______________________________________________
> > equinox-dev mailing list
> > equinox-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> >
> >
> >
> > _______________________________________________
> > equinox-dev mailing list
> > equinox-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> >
> >
> > _______________________________________________
> > equinox-dev mailing list
> > equinox-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> >
> >
> > _______________________________________________
> > equinox-dev mailing list
> > equinox-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/equinox-dev(See attached file:
> smime.p7s)_______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> [attachment "smime.p7s" deleted by Matthew Flaherty/Westford/IBM]
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev

Back to the top