Signing applet code does not grant all-permissions (since 7u25)

There are two levels of authorization for Java applets and web start applications: sandboxed, where the application is limited in terms of actions it can take on users' computers, and all-permissions, where applications operate as though they were native, with full access to the system and its resources.

In the old days of Java 6 and early days of Java 7, the rule was that only applications that required all-permissions needed to be signed. Since Java 7 update 21 (April 2013), you are able to (and encouraged) to sign all types of applications: sandbox and all-permissions. The intent of this is that code signatures from trusted certificate authorities provide a means of authentication for end users, so that they can know who actually wrote the application.

Java 7 update 25 also introduced two new attributes within a jar's Manifest file aimed at Preventing RIAs from Being Repurposed. By having these attributes within the signed jar, attackers cannot make any adjustments to the permissions level without invalidating the signature. An example of the META-INF/MANIFEST.MF file with these attributes would be:

Manifest-Version: 1.0
Created-By: 1.7.0_25
Permissions: sandbox
Codebase: https://example.com

Name: Clazz.class SHA1-Digest: HASHSTUFF=

Beginning January 2014, code signatures and use of the Permissions attribute will be mandatory for all Applets and Web Start applications. The Codebase attribute will remain optional, as ISVs may not know this information beforehand.

These changes create a separation between three areas of trust:

  1. Identification: provided by the application, stating its publisher.
  2. Authentication: automatic by the JRE, the code signatures within JARs is verified against public certificate authorities and dynamically updated revocation lists.
  3. Authorization: once authentication has occurred, allow the application to ask the user for a specific set of permissions.

For additional information about the role of code signatures, sandboxed or not, see our previous blog entry, Code signing: Understanding who and when.

Comments:

So from user side I don't know if a Applet will just making some visual effects or is scanning my system - it's signed. Before this stupid idea unsigned Applets stand for sandbox, secure.

Bye bye Java!

Posted by guest on September 18, 2013 at 08:32 AM PDT #

Signed applets can run with either sandbox or all-permissions. The change here is that the use of a code signature does not imply permissions in either direction. Users will be able to identify permissions based on what the applet requests.

Posted by costlow on September 18, 2013 at 09:40 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

Science Duke
This blog contains topics related to Java SE, Java Security and Usability. The target audience is developers, sysadmins and architects that build, deploy and manage Java applications. Contributions come from the Java SE Product Management team.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
2
3
4
5
6
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today