Security for Applications

Introduction

Security for applications builds on the domain based trust model introduced in IMP-NG, and adopts the class based permissions from the rest of the Java platform. The domain model is used to assign applications to protection domains.

The Permission classes used in the other Java™ Platform Editions are leveraged to provide extensible Permissions, for example to be able to provide access to a single property, resource or function. In contrast, former permission models provided only boolean permissions. Refer to the backward compatibility section for IMP-NG Security.

The use of Permission classes allows the APIs in this specification and in separate optional package specifications to have a single consistent Permission definition on all configurations and profiles. Currently, optional packages that must be defined for CLDC, or CDC and Java SE must have different permission definitions depending on the configuration they are used with. The unification of Permissions simplifies specification, implementation, developer use and conformance testing.

Sensitive APIs and functions use permissions to restrict access. Each API defines the Permissions needed to allow access to the API. Any API or function of this specification which is not security sensitive, having no permissions defined for them, are implicitly accessible by all application suites.

Application Suite Trust Model

Security for application suites is based on protection domains. Each protection domain defines the Permissions that may be granted to an application suite in that domain. The protection domain owner specifies how the device identifies and verifies that it can trust an application suite and bind it to a protection domain. An application suite is bound to a domain during installation and MUST remain bound to the same domain until it is deleted. The mechanisms the device uses to identify and trust application suites are defined separately to allow them to be selected appropriately to the device, network, and business case. Application suites that are identified as untrusted must execute in a secure domain defined as a restricted environment where access to protected APIs or functions is not allowed. The Security Policy Chapter defines one model of a policy for the protection domain(s). Implementations are free to use other policy models being defined outside this specification. Implementations are also free to configure the provider of the policy and the mechanism of the provision of policies. This is out of scope of this specification as well.

Application Suites Trust Model Using X.509 PKI describes one possible mechanism for identifying trusted application suites through signing and verification. Implementations of this specification MUST recognize application suites as being signed. Application suites

Table 6-1 : Definition Of Security Terms

Term

Definition

Protection Domain

A set of Permissions that may be granted to an application suite

Permission

A Permission class defined for an API or function to prevent it from being used without authorization

Function group

A collection of Permissions protecting similar resources or functions. Primarily used for optimising user experience.

Trusted Application Suite

An application suite that is

a) allowed to be installed, and

b) for which the authenticity and the integrity of the JAR can be verified by the device, and

c) bound to a protection domain.

Implementations can decide that all application suites are trusted, or t can recognize application suites as being signed using PKI as specified in Application Suites Trust Model Using X.509 PKI, or it can recognize trusted application suites by other mechanisms, defined outside the scope of this specification.

Untrusted Application Suite

An application suite that is

a) allowed to be installed, and

b) for which the authenticity and the integrity of the JAR can not be verified by the device and

c) bound to a designated protection domain.

This applies only if the implementation requires an authentification and verification of JARs in order to recognize an application suite as being trusted, otherwise all application suites are a priori trusted.

Authorization Model

The basic authorization of an application suite is established by the relationships between the following elements:

Assumptions

Protection Domain

A protection domain defines a set of Permissions. Those permissions explicitly allow access to a given protected API or function on the basis of an application suite being associated with the protection domain. In the MEEP-1.0 profile user interactions MUST NOT be required by the implementation. If the application developer wants to require user confirmations (in case an appropriate user interface is available), he has to code this individually.

Permissions

Permissions are the means to protect access to a single property, resource or function which require explicit authorization before being executed. Whenever such protection is needed, each API must define the Permission classes and parameters of each protected function. Permissions are subclassed from java.security.Permission. Each API may define new Permission subclasses or may use existing Permission classes such as java.security.BasicPermission. New Permission classes should be defined in the package they protect. Permission checks are performed by calling java.security.AccessController.checkPermission. Permissions MUST be checked by the implementation during the execution of the protected function. By calling java.security.AccessController.checkPermission an application is able to check if a certain permission is allowed by the security policy or not.

Permissions for APIs use and extend the Permission classes defined in the underlying configuration CLDC-8. Applications check if a Permission is allowed by the security policy using the checkPermission method of java.security.AccessController. When a Permission is not granted the java.security.AccessControlException, a subclass of java.lang.SecurityException, is thrown.

For more detail please refer to the CLDC-8 specification.

Recommendation for Permissions for Optional Packages

Each API in this specification that provides access to a protected function defines the needed Permissions. For APIs defined outside this specification, there must be a single document that specifies the permissions and the behavior of the API when it is implemented with this specification. New API specifications and maintenance releases of existing APIs targeted at CLDC-8 configuration MUST define the permissions and require those permissions to be used if the underlying configuration includes the java.security.Permission class. To work with existing versions of APIs that have not yet defined Permission classes however, simultaneous use of both named permissions and Permission classes is allowed.

Requesting Permissions for an Application Suite

All application suites that require access to protected APIs or functions MUST request the corresponding Permissions with the MIDlet-Permission-<n>, MIDlet-Permission-Opt-<n>, MIDlet-Permissions, and MIDlet-Permissions-Opt attributes. Permissions requested using zero or more MIDlet-Permission-<n> and MIDlet-Permissions attributes are critical to the function of the application suite and it will not operate correctly without them. In some cases, it is not possible to request permissions for specific resource names in the attributes; for example, the file paths corresponding the application suite's private data may not be known. In other cases, the protection domain policy may vary from device to device and access to a particular resource may not be consistently allowed; for example, access to the property containing the device or user identification. In these cases, the application must defer until runtime the identification of the resource and be prepared to handle its absence or the lack of access due to device policy. If the application suite can function correctly without access to the resources requested by the Permission(s), it should request them using the MIDlet-Permission-Opt-<n> and MIDlet-Permissions-Opt attributes. The application suite is granted only as much access as allowed by the protection domain policy, which will in some cases be less than was requested. The application suite must be able to operate correctly without access to the resources requested in the permissions. All requested permissions are checked against the policy as specified in Granting Permissions to Application Suites.

Each MIDlet-Permissions and MIDlet-Permissions-Opt attribute contains a list of one or more permissions. Multiple permissions are separated by a comma (Unicode U+002C). Leading and trailing whitespace (Unicode U+0020) and tabs (Unicode U+0099) are ignored.

Each MIDlet-Permission-<n> and MIDlet-Permission-Opt-<n> attribute contains a single Permission request and SHOULD be used over their MIDlet-Permissions and MIDlet-Permissions-Opt counterparts if the requested Permission class exists. The lowest value of <n> MUST be 1 and consecutive ordinals MUST be used. The first missing attribute terminates the list. Any additional attributes MUST be ignored. The value of the attribute has the following fields separated by whitespace :

Some examples of class-based Application Permissions are :

    MIDlet-Permission-1: javax.microedition.io.HttpProtocolPermission "http://*:*"
    MIDlet-Permission-2: javax.microedition.io.SocketProtocolPermission "socket://:4321"
    MIDlet-Permission-Opt-1: java.lang.PropertyPermission "*" "read"
    

Authorization of application suites uses protection domain information and critical and non-critical Permissions requested in the application suite. Verification of requested Permissions results in failed installation of an application suite and the Status Code 910 (Application authorization failure) returned in the status report if any of the following errors occur:

LIBlet Permissions

LIBlets MUST declare their required access to protected APIs or functions by requesting the corresponding permissions. Critical permissions are declared using zero or more LIBlet-Permission-<n> and LIBlet-Permissions attributes. Non-critical permissions are declared using zero or more LIBlet-Permission-Opt-<n> and LIBlet-Permissions-Optattributes. Each LIBlet-Permission-<n> and LIBlet-Permission-Opt-<n> attribute contains a single permission request and SHOULD be used over their LIBlet-Permissions and LIBlet-Permissions-Opt counterparts if the requested Permissions class exists. For the value of the attribute, see Requesting Permissions for an Application suite.

The LIBlet by itself will not be bound to any security protection domain independently. The LIBlet is executed inside the protection domain of the application it is bound to. The LIBlet-Permission-<n> and LIBlet-Permission-Opt-<n> attributes MUST NOT be treated as a permission request to the AMS. It is the application that makes the permission requests using MIDlet-Permission-<n> and MIDlet-Permission-Opt-<n> attributes.

LIBlet-Permission-<n>, LIBlet-Permission-Opt-<n>, LIBlet-Permissions and LIBlet-Permissions-Opt attributes are used for declarative purpose; that is, an application suite developer can instantly see which protected APIs or functions a given LIBlet needs to access. Since a LIBlet itself is able to depend on other LIBlets, it is crucial that all permissions requested in the application dependency chain are listed under MIDlet-Permission-<n>, MIDlet-Permission-Opt-<n>, LIBlet-Permissions and LIBlet-Permissions-Opt attributes. Only permissions requested in an application suite will be validated at installation time. Permissions requested in MIDlet-Permission-<n>, MIDlet-Permission-Opt-<n>, LIBlet-Permissions and LIBlet-Permissions-Opt attributes are the union of Permissions required by application suite and all LIBlets in the dependency declaration chain. If any LIBlet-Permission-<n>, LIBlet-Permission-Opt-<n>, LIBlet-Permissions, or LIBlet-Permissions-Opt permissions requested by a LIBlet are not also requested by dependent application suite, then a runtime security exception may occur.

Granting Permissions to Application Suites

The Permissions granted to an application suite are based on protection domain and the Permissions requested in the application suite. The Permissions granted to the application suite are established by the following:

Example of Granting Permissions to Application Suites

An example illustrates the steps used to determine the permissions granted to an application suite. It focuses on the permissions that are available to the application.

For these examples the security domain policy contains permissions:


    grant allowed "NetAccess" {
        permission javax.microedition.io.HttpProtocolPermission "http://*";
    }
    grant allowed "PhoneCall" {
        permission CallPermission "tel://*";
    }
    grant allowed "PrivateFiles" {
        permission javax.io.FilePermission "file:///User1/Home" "read,write";
    }
    grant allowed "WriteLog" {
        permission java.util.PropertyPermission "Logfile" "read,write"
        permission java.util.PropertyPermission "microedition.*" "read";
    }
            
Permission Example Using Required and Optional Permissions

In the first example, the application suite requires access to the network and to a property and makes optional requests to read all properties and access all files:


    MIDlet-Permission-1: javax.microedition.io.HttpProtocolPermission "http://myhost.com"
    MIDlet-Permission-2: java.util.PropertyPermission "Logfile" "write"
    MIDlet-Permission-Opt-1: java.util.PropertyPermission "*" "read"
    MIDlet-Permission-Opt-2: javax.io.FilePermission "file:///*" "read,write"
            

When the application suite is executed the resulting set of permissions granted is in conformance with the verification steps described in section Granting permissions to Application Suites". The permissions granted are:


    grant allowed "NetAccess" {
        permission javax.microedition.io.HttpProtocolPermission "http://myhost.com";
    }
    grant allowed "PrivateFiles" {
        permission javax.io.FilePermission "file:///User1/Home" "read,write";
    }
    grant allowed "WriteLog" {
        permission java.util.PropertyPermission "Logfile" "write"
        permission java.util.PropertyPermission "microedition.*" "read";
    }
            

In this first example, the java.io.FilePermission requests access to all possible files but because it is requested in the MIDlet-Permission-Opt-2 attribute the access granted is the narrower of the request and the protection domain policy. The CallPermission in the domain is not granted because the application suite did not request it. The javax.microedition.io.HttpProtocolPermission is granted only to the requested host even though the domain allows access to any host. The java.util.PropertyPermission to write the "Logfile" property is granted because it is requested and is allowed by one of the java.util.PropertyPermissions in the domain policy. The application suite is granted access to the "microedition.*" properties since it was requested in the MIDlet-Permission-Opt-1 attribute, but only for the narrower of the requested permission and the protection domain permission.

Permission Example Using Only Required Permissions

In the second example, the application suite requires all permissions to operate correctly and uses only the MIDlet-Permission-<n> attributes.


    MIDlet-Permission-1: java.util.PropertyPermission "*" "read"
    MIDlet-Permission-2: javax.io.FilePermission "file:///*" "read,write"
            

In this second example, the installation fails because permissions are denied. The java.io.FilePermission requires access to all possible files. But because the protection domain policy permission is narrower, access must be denied. The java.util.PropertyPermission requires access to all properties. But because the protection domain permission is narrower access must be denied.

External Domain Policy Format

An external representation for protection domains allows clear communication between developers, operators, and manufacturers. Implementations MAY use the external domain policy format to configure security policy and MAY support other policy representations. Provisioning of security policy is outside the scope of this specification.

The format includes all aspects of a domain policy including the domain name, optional bindings to Protection Domain Root Certificates (if the binding is certificate based), and permissions grouped when applicable.

The policy format uses the UTF-8 encoding and semantics for granting permissions to eligible applications. A policy consists of a number of “grant” clauses; each clause contains one or more Permissions. The grant clauses define which permissions requested by applications are granted.

The general form of the format is :

The following is an ANTLR grammar of the external domain policy format. For information about ANTLR, see www.antlr.org.


    grammar domain_policy;

    domain_policy:      domain+;
    domain:     'domain' Identifier root_dn_subjects? ';' grant+;

    root_dn_subjects:   Identifier ( ',' Identifier )* ;

    grant: 'allowed' grant_name permissions;

    grant_name: '"' Identifier '"';

    permissions: '{' permission+ '}';

    permission: 'permission' permission_class target_name? target_action? ';';

    permission_class: Identifier ( '.'  Identifier)*;
    target_name: '"'  ( .~('"')+) '"';
    target_action: '"' ( .~('"')+) '"';

    start       :       .+;

    ALPHA:      ('a'..'z'|'A'..'Z');
    DIGIT:       '0'..'9';
    SYMBOL      :       ('*' | ':' | '/' );
    Identifier: ALPHA (ALPHA | DIGIT)*;
    WS: (' '|'\t'|'\n'|'\r')+ ;
    

A brief example below illustrates the format. Refer to Appendix B for security policy examples using this format.


    domain Sample1;
    grant allowed {
        permission java.util.PropertyPermission “java.version”;
    }

    grant allowed {
        permission javax.microedition.io.HttpProtocolPermission “http://*”;
    }
    

Combined Usage of Recent and Previous Security Models

As optional JSRs are gradually updated to incorporate the permission model of this specification and provide the appropriate Permission classes, developers may face situations where the JSRs used by the application have not yet provided the appropriate Permission classes. As a transitional mechanism, the simultaneous use of both the IMP-NG permission attributes and MEEP-1.0 permission attributes is allowed.

The MIDlet-Permission-<n> or MIDlet-Permission-Opt-<n> attributes may appear in the same JAD and JAR Manifest as the MIDlet-Permissions and MIDlet-Permissions-Opt attributes. In such a case, all permissions requested by all MIDlet-Permission-<n>, MIDlet-Permission-Opt-<n>, MIDlet-Permissions, and MIDlet-Permissions-Opt attributes MUST be verified against the protection domain. If the application suite does not have sufficient authorization for any of the critical permissions requested by MIDlet-Permission-<n> and MIDlet-Permissions attributes, the installation MUST fail and return the Status Code 910 (Application authorization failure). For permissions requested via the MIDlet-Permission-Opt-<n> and MIDlet-Permissions-Opt attribute, the application suite will be granted only as much access as is allowed by the protection domain policy, which will in some cases be less than was requested.

The LIBlet-Permission-<n> or LIBlet-Permission-Opt-<n> attributes may appear in the same JAD and JAR Manifest as the LIBlet-Permissions and LIBlet-Permissions-Opt attributes. These permission attributes are declarative and MUST NOT be treated as a permission request to the AMS.