| Bit9 Parity Agent and RCP apps [message #873743] |
Fri, 18 May 2012 21:09  |
Eclipse User |
|
|
|
Is there anyway to sign RCP application so they get along with Bit9 (a security / application control system on Windows, see bit9.com)?
I have been given instructions to sign an EXE or DLL which I create. I can follow these instructions and sign the launcher application (eclise.exe for my RCP). That allows the launcher to execute.
bit9 stops the SWT*.dll unless it already has been give approval for that version and release (*). Any other ddl will be blocked by bit9.
The security department will give a user a half hour window to install an application. During this window unknown EXE and DLL are recorded and approved.
Does anyone have ideas how to live with this? I've searched both Eclipse.org and bit9.com for posts, articles or docs on how to improve the interaction between bit9 and Eclipse. No joy.
I was thinking that a class, or set of classes, that did nothing except to force the different DLLs in Eclipse to load would make the authorization process easier.
A complicated eclipse application, the eclipse IDE for example, may not touch all the DLLs it could touch (in /plugins) eventually. After loading the IDE this set of classes could be execute which would cause the DLL to be loaded and recoginized by Bit9.
I'd appreciate any references to documentation or experience anyone can share on this.
Thanks
Bill Blalock
|
|
|
|
| Re: Bit9 Parity Agent and RCP apps [message #875414 is a reply to message #874293] |
Tue, 22 May 2012 13:50  |
| Eclipse User |
|
|
|
Thank you for looking at this Vivek.
When creating an RCP the only Windows part that is created is the launcher, eclipse.exe or my_project.exe. The launcher can be signed.
The other DLLs which an RCP project uses are those provided by Eclipse and any third party plug-ins or jars (for example Java Advanced Imaging has 3 DLL so graphics can be handled with native mechanisms. The Eclipse DLLs are packaged in jar (Java Archive) files.
I doubt that Eclipse built-in security would allow removing the DLLs from the distribution jars, signing them and putting them back into the distribution jars.
Eclipse framework and Java loads DLL when it needs them. When Eclipse or an Eclipse RCP in installed on a Bit9 protected PC only the DLLs used by the install process, or called by running an Eclipse project or the Eclipse RCP during the installation time period, are recognized by Bit9.
DLLs called after the unlock period expires are blocked by Bit 9.
This is an example of the Bit9 / Eclipse problems we are having:
I received a new desktop with Bit9. Support put in the code to unlock the parity agent. I installed JDK 6 rel 32, copied IDE folder from my laptop to desktop and ran some of my projects.
These are the DLLs I have found in Indigo:
DLL's packaged in C:\eclipse_ide\eclipse_indigo_RCP\plugins\org.eclipse.swt.win32.win32.x86_3.7.1.v3738a.jar
swt-awt-win32-3738.dll
swt-gdip-win32-3738.dll
swt-webkit-win32-3738.dll
swt-wgl-win32-3738.dll
swt-win32-3738.dll
swt-xulrunner-wi8n32-3738.dll
DLL's packaged in C:\eclipse_ide\eclipse_indigo_RCP\plugins\org.eclipse.core.net.win32.x86_1.0.100.I20110331-0827.jar
jWinHttp-1.0.0.dll
DLL's packaged in C:\eclipse_ide\eclipse_indigo_RCP\plugins\org.eclipse.core.filesystem.win32.x86_1.1.300.v20110423-0524.jar
localfile_1_0_0.dll
DLL's packaged in C:\eclipse_ide\eclipse_indigo_RCP\plugins\org.eclipse.core.resources.win32.x86_3.5.100.v20110423-0524.jar
win32refresh.dll
DLL's packaged in C:\eclipse_ide\eclipse_indigo_RCP\plugins\org.eclipse.equinox.security.win32.x86_1.0.200.v20100503.jar
jnicrypt.dll
DLL's packaged in C:\eclipse_ide\eclipse_indigo_RCP\plugins\org.eclipse.update.core.win32_3.2.200.v20100512.jar
update.dll
DLL's packaged in C:\eclipse_ide\eclipse_indigo_RCP\plugins\org.eclipse.wb.os.win32_1.1.0.r37x201109091012.jar
wbp.dll
During my install these DLL were unbundled and I presumed recognized by Bit9:
C:\eclipse_ide\eclipse_indigo_RCP\configuration\org.eclipse.osgi\bundles\71\1\.cp\os\win32\.cp\jWinHttp-1.0.0.dll
C:\eclipse_ide\eclipse_indigo_RCP\configuration\org.eclipse.osgi\bundles\68\1\.cp\os\win32\x86\localfile_1_0_0.dll
C:\eclipse_ide\eclipse_indigo_RCP\configuration\org.eclipse.osgi\bundles\475\1\.cp\swt-gdip-win32-3738.dll
C:\eclipse_ide\eclipse_indigo_RCP\configuration\org.eclipse.osgi\bundles\475\1\.cp\swt-win32-3738.dll
The Bit9 app control error, block, occured when the IDE tried to use this DLL
C:\eclipse_ide\eclipse_indigo_RCP\configuration\org.eclipse.osgi\bundles\521\1\.cp\os\win32\x86\wbp.dll
I thought Bit9 would register more of these DLLs if I had a set of classes which touched each of these DLLs, forcing them to be unbundled for their delivery jar, and ran these classes during the installation while Bit9 was unlocked.
I am asking for other community members experience with Eclipse and Bit9.
There doesn't seem to be alot available now on getting Bit9 and Eclipse to work together. I didn't find anything on bit9.com for "Eclipse" and I didn't find anything on eclipse.org searching for "bit9" in terms of application control.
Thanks
Bill Blalock
[Updated on: Wed, 23 May 2012 16:44] by Moderator |
|
|
| Re: Bit9 Parity Agent and RCP apps [message #876874 is a reply to message #875414] |
Fri, 25 May 2012 08:39 |
| Eclipse User |
|
|
|
Thanks for the detailed explanation of the issue Bill.
Resolving the issue will require involvement of the Bit9 Administrator at FIS. I also recommend that the remediation steps are done in conjunction with Bit9 support personnel. They would be more than happy to help implement the following steps.
1. Add *.jar files to the agent property file_patterns_to_deep_crawl and enable this agent prop.
2. Allow this configuration change to propagate to all agents.
3. Create a Trusted Directory and put the eclipse installer in the trusted directory.
4. Allow the approvals created as a result to propagate to all agents.
5. If you do not use trusted directories in your environment, it is recommended to delete the trusted directory created for the purpose.
I hope this helps.
|
|
|
Powered by
FUDForum. Page generated in 0.07524 seconds
Home