|
Re: ANNOUNCEMENT - Security "Work Area" in Equinox/Eclipse [message #46351 is a reply to message #46320] |
Tue, 18 January 2005 22:20 |
Ted A. Habeck Messages: 7 Registered: July 2009 |
Junior Member |
|
|
Jay Rosenthal wrote:
> Please see the update overviews in the Security work area of Equinox. The
> goal of the work area is to further discussion and developement of Eclipse
> and the Eclipse RCP as a secure application platform.
>
> http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/security/index.html
>
Starting Eclipse 3.0 with a SecurityManager enabled to run with Java 2
security turned on requires a custom tailored java policy for the
installed codebase. Specifically, it requires granting
java.security.AllPermissions to all the .jar files in the OSGI plug-ins
classpath.
Using an automated static-analysis tool, I've been analyzing the code to
identify Java 2 security permission requirements for the Eclipse 3.0
codestream. I have been modifying the codebase to enable Java 2
security. This has included adding calls to
AccessController.doPrivileged() to prevent plug-ins from requiring
unnecessary permissions. Thus far I've completed updates to 50% of the
org.eclipse.osgi_3.0.0 plugin. Detailed reports on the current analysis
are available at URL:
http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/security/EJS/ejs.html.
To enable Java 2 security for the RCP, a few more plugins will need to
be modified. This includes SWT and UI, which will be a bit more
challenging!
Additional Java 2 related security background documentation is available
from the sources appended at the bottom of this posting.
I'd like to open up the discussion of this work.
Thanks.
Ted
References:
Books:
“Java 2 Network Security” Second Edition (June 1999). Marco Pistoia,
Duane F. Reller, Deepak Gupta, Milind Nagnur, Ashok K. Ramani.
http://www.redbooks.ibm.com SG24-2109-01.
“Inside Java™ 2 Platform Security”, Second Edition. Li Gong, Gary
Ellison, Mary Dageforde. http://www.javaseries.com Addison-Wesley ISBN
0-201-78791-1.
“Enterprise Java™ Security” Marco Pistoia, Nataraj Nagaratnam, Larry
Koved, Anthony Nadalin. Addison-Wesley ISBN: 0-321-11889-8
Web sites:
http://www.research.ibm.com/javasec
http://java.sun.com/security
|
|
|
Re: ANNOUNCEMENT - Security "Work Area" in Equinox/Eclipse [message #46379 is a reply to message #46320] |
Thu, 20 January 2005 20:52 |
Christophe Elek Messages: 38 Registered: July 2009 |
Member |
|
|
"Jay Rosenthal" <jrosenth@notesdev.ibm.com> wrote in
news:csjbg2$75p$1@www.eclipse.org:
> Please see the update overviews in the Security work area of Equinox.
> The goal of the work area is to further discussion and developement of
> Eclipse and the Eclipse RCP as a secure application platform.
>
> http://dev.eclipse.org/viewcvs/indextech.cgi/~checkout~/equi nox-home/se
> curity/index.html
>
There are couple thinks we investigated when we first started Update
Manager, I will post them here, who knows :)
1) It seems there is an ANT task to allow signing JAR
http://ant.apache.org/manual/CoreTasks/signjar.html
2) the Update Manager follow java.policy and java.security when searching
for a truststore: see spec
3) There is a way to specify a truststore on an HTTP server (so you can
share it)
4) We could not find a way to prevent execution of loaded plugin because
eclipse is by essence running in a non-secure environment (the machine of
the hacker). Even encrypting bytecode (heavy) could be cracked
5) There was some kind of basic cert management and password management
in WebDav (I used the code in UM but did not persist)
6) Certificate and Identity management is usually not performed by the
user. or some advanced user then. Managing certificate, CRL and other PKI
is not 'very' user friendly
7) controlling what is loaded or not must be done in a central secure
location either at the customer site or centrally in a secure site from
the company (see #4)
8) JAAS was not present :) so we tried to see if we could implement the
notes kind of ACL and authentication, but it linked back to #7, central
secure place.
9) We defined the 'secure site' for Update Manager, delegating (what can
be seen) to teh owner of the site using server side computation. The
Authentication and authorization mechanism works today but is part of the
server (We demoed it with a servlet that dynamically lists the update you
are allowed to see)
9) I still believe certificate management (Authentication), pure user
Authentication and Authorization are different 'beasts' especially is
used in the desktop or embedded environment
10) We should support HTTPS now as I believe all eclipse ref to resources
uses URL and JDK 1.4 supports JSSE no ?
11) We thought about having eclipse or the products based on eclipse,
deliver their own JDK with their own certificate in cacerts. This would
have required eclipse or other product to 'sign' updates with their
certificate which could be cheaper than buying one from Verisign or
thawte. It was complex and we did not have the technology to update the
JDK from update manager
That is all I remember now :)
Cheers, I would be happy to help if I can
--
Christophe Elek
Complex and difficult problem resolution specialist
IBM Software Groupe - Support
Eclipse Project - Update Core
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03318 seconds