JDK-8031993 : Provide API to check if a given DRS allows or blocks a given application
  • Type: Enhancement
  • Component: deploy
  • Affected Version: 6-pool,7-pool,8
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-01-16
  • Updated: 2014-07-29
  • Resolved: 2014-06-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u20 b19Fixed 9Fixed
Related Reports
Duplicate :  
JDK-8043973 - Provide API to parse deployment rulesets from XML
Relates :  
JDK-8043973 - Provide API to parse deployment rulesets from XML
Relates :  
JDK-8031989 - Provide API to get all the JNLP artifacts
Description
This is a request from Java SE Advanced team. We're implementing a tool that will allow Java administrators collect statistics about Java applications (with Java Usage Tracker) and create deployment ruleset based on the collected data.

One of the tool requirements is to provide a dry-run mode functionality. That is, for any deployment ruleset and any application (applet, Web Start app) check if the application is blocked or allowed by the ruleset.

Exact algorithm that is used by deployment code to process DRS files is very likely far from trivial. JNLP applications can have multiple jars, multiple extensions, signed with different certificates. It makes this dry-run feature difficult to implement without support from the Deployment team.

I see two different approaches to implement the dry-run functionality:

1. Launch real applet or Web Start application, but use a different DRS. By default, DRS is loaded from a well-known location (e.g. %WINDIR%\Sun\Java\Deployment\), so API to load it from another place is required.

2. Don't launch anything, but simulate DRS processing. So the API will be to accept an application URL and a DRS, and the output will be "run" (and Java version used to run) or "block".

The latter approach is preferable from the performance point of view.
Comments
Crucible review: https://java.se.oracle.com/code/cru/CR-JDK9CLIENT-316
30-05-2014
It is possible for different resources in an app to be covered by different rules. (for example, with multiple jars in different paths on a given host, a run rule may cover some, but not others, which may or may not be covered by a later rule.) so it is east to implement a check of each resource individually: public static DRSResult check(String ruleSetXml, AppRef appRef, CodeRef codeRef) {} but if we want to implement a check for all of the jars in an app at once such as: public static DRSResult check(String ruleSetXml, AppRef appRef, CodeRef[] codeRefs) {} we either have to make DRSResult a more complex object, or return an array of them such as: public static DRSResult[] check(String ruleSetXml, AppRef appRef, CodeRef[] codeRefs) {} I was thinking the DRSResult would just contain: 1.) The type of result: EXCEPTION, BLOCK, RUN, DEFAULT 2.) The index of the matching rule (or -1 if EXCEPTION type or no rule matched). 3.) The block rule message (if type is BLOCK) 4.) The version and force flag (if type is RUN) 5.) The exception if type is EXCEPTION this may be either a RuleParseException (if either the xml cannot be parsed, or if a rule is invalid for any reason.) or a SecurityException (if path part of url contains unsupported characters, or we get URISyntaxException) initial proposed webrev at: http://oklahoma.us.oracle.com/www/webrevs/aherrick/1.9.0/8031993/
27-05-2014
Comments about items above: 1) DRSTool has its own representation of rulesets, which is basically an ordered list of rules, and a rule is an object with "location", "title", "hash", "run action", "jre version", and "message" fields. We can either export the ruleset to an XML string and pass it to the API, or we can use this internal representation as input. Both are doable and easy from DRSTool perspective. 2) Docbase URL is available. It is the original web page URL for applets (with HTTP/GET params removed), or JNLP file URL for Web Start apps. Resources: we parse "archive" attribute of <applet> tags and all the jars from <resources> in JNLP. Version strings for jar files are available as well. The title is available. Note that at the current moment DRSTool parses this information on its own. JDK-8031989 is about API to get this information from the Deploy team, so whatever information is provided from 8031989 API, exactly the same information will be used in checkApp(). 3) DRSTool is able to download jars and extract certificates / checksums, and we make the same assumption about networking and proxies. So this is not a new requirement. 4) Besides the information whether the app is blocked or permitted, we also need to know what rule from the ruleset blocks/permits the app. 5) We don't support LiveConnect in DRSTool. I sent a question about JavaScript to Thomas, Andy, and David on March 13, 2014, but haven't received any replies.
11-04-2014
alternatively, instead of returning a DeploymentRuleSet, we could return a DRSResultsObject that encapsulated only the needced information.
10-04-2014
In order to check the result of applying a ruleset to an application: 1.) First the entire ruleset must be provided, and the deployment DRS code should parse it. This can either be in the form of a String (containing all the XML) or a File object containing the xml. 2.) The DRS code needs: - the docbase URL (URL of the html page containing an applet, with the Query string removed). This can be null for jnlp applications and extensions. - the jnlp URL (This can be null for non-jnlp applets) - the list of resources, (URLS from "archive", "archive_ex", or jnlp <resources> element, together with the version strings for each) - the title 3.) The code will have to be able to download the resources to extract the certificates and / or checksum. This means the proxies in the JCP must be set up to be able to reach these URLs. 4.) The result of the check should be the DeploymentRuleSet Object, from which the calling tool can get the type (run, block, ro default) as well as message, version, and weather version is forced) 5.) finally there needs to be separate check for live connect, passing in just the ruleset, and docbase package com.sun.deployment.security.ruleset; public class DRSTool { public DeploymentRuleSet checkApp(String rulesetXML, URL docbaseURL, URL jnlpURL, URL [] resources, String [] versions, String title) { } public DeploymentRuleSet checkLiveConnect(String rulesetXML, URL docbaseURL) { } }
10-04-2014
Note that in DRSTool JNLP extensions are treated as separate applications (but we still show what application uses what extensions). So the requested API should not take extensions to consideration, but only application URL, title, and a list of jars. In other words, it can be as simple as boolean matches(String appUrl, String appTitle, Set<String> jarURLs, DeploymentRule rule) Alternatively, we can pass application URL only and let the deployment code to parse everything else: boolean matches(String appUrl, DeploymentRule rule)
04-03-2014
As we discussed in the meeting with Kirill, Marty, and Thomas yesterday, first of all we should agree on the representation of rules and applications. Here is how we represent applications in DRSTool: 1. URL - this is either a web page URL (for applets), or JNLP file URL (for JNLP applets and Web Start apps) 2. Title, vendor, description - for JNLPs 3. Code - main class of the applet/application 4. Security - sandbox/all-permissions 5. Type - applet, application, extensions 6. Jars - set of jar URLs and jar versions. For applets, it's just a single file from the "archive=" attribute. 7. Extensions - mapping extension names to JNLP file URLs. Not all these attributes are used in DRS processing. For example, application type, security mode, or vendor are not used in DRS, but will be displayed for the user to help make a decision if an application should or should not be allowed. Rule representation is very simple: 1. Location 2. Title 3. Certificate alg/hash 4. Run action - run, block, default, force-run 5. Run version - only if the action is "run" 6. Message + locale
04-03-2014
Ideally DRSTool should be able to reuse Rule, RuleId, RuleAction, DeploymentRuleSet classes, as well as call into RuleId.contains(). Are these OK to reuse from application code? Can we consider them stable?
17-01-2014