Skip to end of metadata
Go to start of metadata

Rules

Risk Assessment Summary

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

ENV00-JHighProbableMedium

P12

L1

ENV01-JHighProbableMedium

P12

L1

ENV02-JLowLikelyLow

P9

L2

ENV03-JHighLikelyLow

P27

L1

ENV04-JHighLikelyLow

P27

L1

ENV05-JHighProbableLow

P18

L1

ENV06-JHighProbableLow

P18

L1

 


5 Comments

  1. Three of the five recommendations have the same basic mitigation. ENV01-J, ENV02-J, and ENV03-J all show

    ${JDK_PATH}/bin/java -Djava.security.manager ApplicationName
    

    as the complaint example. They differ in other stuff to be done or considered. If we are are looking to minimize the number of recommendations this is a place to start. My quick read is that ENV01-JandENV02-Jare sufficiently close that a single recommendation may be possible.ENV03-Jseems pretty different to me. If we are not trying to find a smallest set of recommendations this comment can be safely ignored

    1. That is a good observation. However, we are separating the topics because they differ significantly. Moreover, this helps tool vendors enforce the guidelines.

      Other notes: Currently, the guidelines are arranged in no particular order. Once the wiki is more stable, they will be reordered for ease of reading.

  2. Something similar is happening in the rules with respect to the following mitigation.

     protected PermissionCollection getPermissions(CodeSource cs) {
      PermissionCollection pc = super.getPermissions(cs);
      // other permissions
      return pc;
    }
    

    It appears in ENV31- J, ENV32-J, and ENV33-J. I believe that it may be possible to write a single rule in the form of Do and opposed to three rules in the form of Do not. Furthermore the new rule, like the three old ones, seems suitable for automated detection. I'll wait for some guidance before adding more comments of this sort.

    1. Yes these are very similar in their goal. In fact, applications should not grant other privileges if they are not required. AllPermission, Reflection and Classloading have been separated because these are some of the more dangerous permissions. This separation consumes more space but is better for clarity. For example, the severity of all these guidelines differ (high to low): AllPermission, Classloading and Reflection. A program that grants permissions to trusted code to create a classloader or permits reflection is better than the one that uses AllPermission.

      1. Perhaps ENV 3,4,5 should be clubbed into a single guideline now.