Bugzilla – Full Text Bug Listing
| Summary: | Add security support to New Agent Controller | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Igor Alelekov <igor.alelekov> | ||||||||||||||||||||||||||||||
| Component: | TPTP | Assignee: | Igor Alelekov <igor.alelekov> | ||||||||||||||||||||||||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||||||||||||||||||||||||
| Severity: | critical | ||||||||||||||||||||||||||||||||
| Priority: | P1 | CC: | chris.l.elford, guru.nagarajan, igor.alelekov, jcayne, jgwest, jkubasta, kiryl.kazakevich, nelliec, paulslau, samwai, sluiman, srinivas.p.doddapaneni, stoian, xubing | ||||||||||||||||||||||||||||||
| Version: | unspecified | Keywords: | plan | ||||||||||||||||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||||||||||||||||
| Hardware: | PC | ||||||||||||||||||||||||||||||||
| OS: | All | ||||||||||||||||||||||||||||||||
| URL: | http://www.eclipse.org/tptp/groups/Architecture/documents/features/hf_195644.html | ||||||||||||||||||||||||||||||||
| Whiteboard: | closed460 | ||||||||||||||||||||||||||||||||
| Bug Depends on: | |||||||||||||||||||||||||||||||||
| Bug Blocks: | 74579, 206875, 206878 | ||||||||||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||||||||||
|
Description
Igor Alelekov
What interface are you considering using for the SSL? A proxy of some sort or an embedded interface like openssl? (In reply to comment #1) > What interface are you considering using for the SSL? A proxy of some sort or > an embedded interface like openssl? Since the AC is native I would like to use a native solution. I've chosen openssl as most Linux distributions come with precompiled openssl package and it is fully compatible with JSSE used in TPTP clients. On Windows we also can use openssl but it is required to be installed separatelly. I'm going to try Win API instead of it, I thought it might be more light solution. Created attachment 73419 [details]
Platform.Execution patch
Implementation consists of 5 patches.
This is the patch for the Platform.Execution component.
Created attachment 73421 [details]
Platform.Common.UI patch
Created attachment 73422 [details]
JVMTI.Client patch
Created attachment 73423 [details]
Hyades.Trace.UI patch
Created attachment 73425 [details]
Agent Controller patch for Linux
Client patches implement security for all platforms. AC patch do this for Linux only. I've tested these patches on Linux and Windows. Currently, security windows code is commented out to avoid build failure. This implementation uses openssl library preinstalled on most Linux builds. On Windows we have two options: - To use the openssl. It requres user to install (optionally) openssl if he intends to use security feature. - To use Win API (Win.SDK) Both option require changes to be made in TPTP build system on Windows. Created attachment 73429 [details]
generateKey.sh
Updated generateKey.sh to generate necessary certificate
Important: using JVMTI profiling with security enabled assumes that patch #187887 is applied.
discuss for 4.5? Igor already has patch under discussion. Igor, as you already have a patch and as this is a major regression, the fix needs to be included in 441. (In reply to comment #11) > Igor, as you already have a patch and as this is a major regression, the fix > needs to be included in 441. OK, I'll test it again tomorrow to ensure it can be checked in. Created attachment 77241 [details]
updated platform.execution patch
Created attachment 77242 [details]
updated platform.common.ui patch
Created attachment 77243 [details]
updated AC patch
All 3 patches checked into 4.4.1 (head). Igor please mark this as fixed. Thanks. Resolving as fixed Igor, shipping with a dependency on OpenSSL is not acceptable to TPTP. Could you please work to find an alternate solution? Thanks. I don't know. I saw two ways only - to use external ssl library or to implement this one by ourself. Obviously, implementing a whole SSL stack is not really viable... The potential options here seem to be: (1) use JNI upcalls to the JSSE implementation (The old AC used JSSE) This is not desirable because the new AC attempts to disassociate itself from the need for an underlying JVM. Adding such a dependence seems a questionable decision. Especially if we intend to yank it for an OpenSSL solution in 4.5. (2) Wait for TPTP 4.5 The real problem is that we cannot add a dependence in a 3rd point release (e.g., 4.4.1). We can add a dependency in a 2nd point release (e.g., 4.5). Personally, I'm wondering if this is the direction that we're going to need to end up with. (3) Pull in the OpenSSL codebase OpenSSL is licensed under a BSD style license. I know that we cannot add an external dependence in a point release. Is it permissible to pull in external code in a point release? (4) If you just want windows support, one could rely on the Windows builtin SSL support. Unfortunately, it looks like it requires Vista if one wants to use the "easy" interfaces... http://msdn2.microsoft.com/en-us/library/bb394815.aspx. (In reply to comment #20) > I think these are good questions to ask and could be discussed in the context of an AG review. We have opposing forces in this discussion. One being that for comsumer products, we have a regression in end user function without a fix, and introducing additional dependencies that consumers would need to approve the lic. off is time consuming if even viable. On the other hand the code base now in use never had this feature and has a design point to be Java agnostic. Coming from the consumer side of this I have a pretty strong bias, and it was made very clear to us that the existing consumers could/would not accept a new dependency like openSSL on short notice or in a patch release. From a consumer point of view the capability was there before and additional external dependencies is not needed. It is not just a matter of lic. it is also a matter of support. I agree with the principal behind the AC design point, but I am not clear on it in the context of tooling that primarily targets Java and uses Java as the setup/config tool runtime. I suggest an AG review of the detailed alternative, and that the consumers ensure they have a voice along with our motivation for the desire to not have a Java dependency. (In reply to comment #20) > (1) use JNI upcalls to the JSSE implementation (The old AC used JSSE) > This is not desirable because the new AC attempts to disassociate itself from > the need for an underlying JVM. Adding such a dependence seems a questionable JNI calls may cause significant overhead. From other hand, using lazy dynamic jvm loading and native implementation of hyades file services (bug #196435) this overhead could be eliminated for users who don't need security features. > (4) > If you just want windows support, one could rely on the Windows builtin SSL > support. Unfortunately, it looks like it requires Vista if one wants to use > the "easy" interfaces... > http://msdn2.microsoft.com/en-us/library/bb394815.aspx. It seems that SSL is available on Windows starting with Windows NT SP 4 and on all versions of Windows 2000 (via schannel.dll). Corresponding examples could be found in Platform.SDK samples. From other hand, separate implementation for each platform requires additional efforts for support. Adding Paul since he is now the AG lead and should facilitate this decision soon. Unfortunately, I won't be able to dial in for AG review tommorrow. My final comments are below... If we wait until 4.5, the implementation is pretty much done (using OpenSSL) and only legal followthru is required. It would be available for users June 30. If we do not wait for 4.5, and go with a lazy loaded JVM and JSSE, the earliest users would get it would be 4.4.1 on Feb 29. By doing some extra work, we would get it to users about 4 months faster. The only technical questions are: * How much work? * How big of an overhead for the JNI? The real question here is less technical. Are enough users requesting it such that this 4 months is critical? If there are enough real users asking for it in a vocal enough fashion, its may be worth doing something for them if the time to fix is reasonable. Are all user complaints on windows or are they on both windows and linux? (This could suggest that using windows schannel may be desirable). I am toying with the concept of JSSE in 4.4.1 and OpenSSL in 4.5. Given that a pure native solution exists, I'm unclear of the value of keeping JSSE via JNI around. However, it seems a waste to me to implement JSSE/JNI model for such a small time period. Eventually when we do TPTP 5, I would hope that we could eliminate the VM altogether from the AC. Setting up more relationships between the new agent controller and the VM is at odds with that goal. Created attachment 80051 [details]
Feature description document
Created attachment 80132 [details]
patch to remove openssl dependency from 441
Hi Samson,
Could you please review the patch.
It removes the dependency of TPTP 4.4.1 on openssl.
Thanks,
Igor
Perhaps we should split this into two features: 1) 441 feature for JSSE/JNI 2) 45 feature for OpenSSL? (In reply to comment #27) > Perhaps we should split this into two features: > 1) 441 feature for JSSE/JNI > 2) 45 feature for OpenSSL? > Yes, except the 4.4.1 work would be under a defect since the missing security with JVMTI constitutes a regression from JVMPI. Ignor, please open a defect for the 4.4.1 work and include the comments from our calls. (In reply to comment #28) > Igor, please open a defect for the 4.4.1 work and include the comments from > our calls. If you agree, I'll open two bugzillas: - enh.request to implement pluggable architecture for ssl providers - defect to track implementation of JSSE security as pluggable module Current defect can be considered as "Implementation of pluggable module for native ssl provider using openSSL library". (In reply to comment #29) > (In reply to comment #28) > > Igor, please open a defect for the 4.4.1 work and include the comments from > > our calls. > > If you agree, I'll open two bugzillas: > - enh.request to implement pluggable architecture for ssl providers > - defect to track implementation of JSSE security as pluggable module > > Current defect can be considered as "Implementation of pluggable module for > native ssl provider using openSSL library". > Hot exactly. The 4.4.1 defect will include the JSSE and pluggable layer. The 4.5 enhancement will include a pluggable OpenSSL implementation. Bug #206878 opened to track implementation of JSSE ssl provider. Bug #206875 opened to track implementation of OpenSSL ssl provider. Pluggable layer will be supported by the current bug. Approved by the AG for TPTP 4.5 with the following comments: -See meetings from review call (http://dev.eclipse.org/mhonarc/lists/tptp-platform-dev/msg02106.html). -Bugzilla 195644 will be converted to a defect, along with defect 206878 (JSSE SSL provider) to provide pluggable security in 4.4.1. -Bugzilla 206875 will provide a SSL provider in 4.5. (In reply to comment #32) For TPTP 4.4.1. Created attachment 80870 [details]
FDD for Pluggable Layer
I would suggest using the following generic functions to retrieve the provider name and info instead of sslGetProviderName() and sslGetProviderInfo(). void sslSetValue(char* name, char* value) char* sslGetValue(char* name) Using these functions will allow better flexibility for passing and retrieving information between AC and the provider. (In reply to comment #35) > I would suggest using the following generic functions to retrieve the provider > name and info instead of sslGetProviderName() and sslGetProviderInfo(). > void sslSetValue(char* name, char* value) > char* sslGetValue(char* name) > Using these functions will allow better flexibility for passing and retrieving > information between AC and the provider. I agree with sslGetValue() and sslSetValue(). But I would like to have provider's name/version written to log file. To ensure that provider will supply this info I'm suggesting that sslGetProviderName() will remain. Created attachment 84612 [details]
Pluggable layer implementation
I have tested this on Windows and Linux with tptpOpenSSL and tptpJSSE ssl provider modules.
For tptpOpenSSL I used SampleSecureClient and regular profiling as test cases.
For tptpJSSE I used SampleSecureClient only, since profiling with JSSE requires additional jvm to create, which is limited. Samson is investigating this issue.
Created attachment 84631 [details]
FD for Pluggable Layer
The patch is checked into CVS head and into 441 branch. Resolving the bug. *** Bug 74579 has been marked as a duplicate of this bug. *** *** Bug 103827 has been marked as a duplicate of this bug. *** As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since the originator of this enhancement/defect has an inactive Bugzilla account and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open. |