Security Policy Providers

Introduction

This chapter sketches the cornerstones of a Security Policy architecture.

All code running under MEEP 8 must be verified upon loading, execute in the Java VM sandbox and must be verified to be authorized before granting access to restricted APIs and resources. This verification is done by permission checks, and the Security Policy Provider is the part of the MEEP 8 implementation providing the policy being the basis for those checks.

All implementations of a Security Policy Provider MUST follow the security framework specified in Security for Applications. The details depend very much on the chosen Authentication Provider. This chapter describes general rules for the implementation of a Security Policy Provider.

One possibility to implement a Security Policy Provider is the mechanism defined in MIDP 3.0, where an application suite is bound to security protection domains based on its signature (and therefore on the client) and then the appropriate permission set for an application is determined. This is the default Security Policy Provider in MEEP 8, and it MUST be supported, if the implementation does not provide an individual one. Details can be found in this chapter. This mechanism expects the default Authentication Provider of MEEP 8 as is defined here or another certificate based authentication provider.

Implementation are free to use the default Security Policy Provider or to provide an individual one. There must be only one Security Policy Provider at any given time though and the implementation of this provider must remain unchanged throughout the runtime of the system. A string describing the current Security Policy Provider can be retrieved as the value of the microedition.security.policy system property as defined in the system properties chapter .

Security for Applications defines the framework for authenticating the source of an application suite and authorizing an application suite to perform protected functions by granting permissions it may have requested, based on the security policy on the device. It also identifies functions that are deemed security vulnerable and defines permissions for those protected functions. Additionally, it specifies the common rules for APIs that can be used together with this specification but are defined in other specifications. This chapter defines extensions to the base application suite security framework in the following areas:

Security Protection Domains

A Client is associated with a Security Protection Domain that defines a policy with a set of permissions that can be granted to an application. The representation of a Security Protection Domain and its security policy is implementation specific. If among the required permissions are those not known to the implementation though, the Security Protection Domain MUST NOT be installed. A concept of unresolved permissions is not supported in MEEP 8, nor is the Security Policy Provider allowed to silently ignore unknown permissions.

An application suite MUST be assigned to one and only one Client. How an application suite is assigned to a Client depends on the Security Authentication Provider used by this implementation. Application suites that cannot be authenticated as per the Security Framework MUST be assigned to a predefined "Untrusted" Client.

If application suites can be identified via more than one way, it depends on the definition of the Security Authentication Provider, which Client the application suite is assigned to.

Each LIBlet that is a dependency of an application is assigned to the Client of the application and is also authenticated by the authentication mechanism of the application. The set of Clients used during provisioning (if supported) to determine which LIBlets may be bound as a Service then. See the provisioning step for resolving service dependencies.

Applications assigned to the "Untrusted" Client run in an unprivileged environment with a policy refusing access to any sensitive APIs and features. In contrast to this, applications assigned to an authorized and trusted Client run in a privileged environment. However, the privileges given to an application might still depend on the specific policy defined in the Security Protection Domain assigned to the Client the application is assigned to.

Potential consequences of a change of the smart card are described in Application Download and Execution While Roaming and After Changing the Smart Card.

The "Untrusted" Client

Application suites that cannot be authenticated will be assigned to a virtual "Untrusted" Client.

This "Untrusted" Client for untrusted application suites MUST allow access to the following packages (if available):

Table 8-1 : Packages Allowed for the "Untrusted" Client

API (if supported by the implementation)

Description

javax.microedition.rms

RMS APIs

javax.microedition.midlet

Application Lifecycle APIs

javax.microedition.media
javax.microedition.media.control

Audio Media APIs (only playing)

Everything not mentioned in the table above SHOULD NOT be available for untrusted applications in order to avoid damage to be caused by malicious applications.

Permissions for Application Suites

The security policy and permissions applied to all application suites that are installed on a device MUST conform to the requirements listed in this section, whether those application suites were preloaded or preinstalled or subsequently provisioned after device manufacture.

Mapping Permissions onto Function Groups for Clients

The high level functions essentially capture and reflect the actions and consequences of the underlying individual permissions. These so-called function groups are as follows:

Whenever new features are added they should be assigned to the appropriate function group. In addition, APIs that are specified elsewhere (that is, in other JSRs) but rely on the security framework should also be assigned to an appropriate function group. If none of the function groups defined in this section is able to capture the new feature and reflect it adequately a new function group MUST be defined in this document by requesting an update to this document from MSA or this specification as appropriate.

If a new function group is to be added, the following should be taken into consideration: the group to be added MUST NOT introduce any redundancy to the existing groups, the new group MUST be capable of protecting a wide range of similar features. The latter requirement is to prevent introducing narrowly scoped groups. The new function group SHOULD be sufficiently future-proof to contain new features added by future APIs and should not only concern the features being initially included in it.

Table 8-4 presents individual permissions and maps them to the function groups specified in this section. An individual permission MUST occur in only one function group.

Table 8-4 : Mapping Permissions to Function Groups

Permission

Protocol

Function group

javax.microedition.io.
HttpProtocolPermission("http://*").
Defined in [CLDC]

http

Net Access

javax.microedition.io.
HttpsProtocolPermission("https://*").
Defined in [CLDC]

https

Net Access

javax.microedition.io.
DatagramProtocolPermission("datagram://*").
Defined in [CLDC]

datagram

Low Level Net Access

javax.microedition.io.
DatagramProtocolPermission("datagram://").
Defined in [CLDC]

datagram server (without host)

Low Level Net Access

javax.microedition.io.
SocketProtocolPermission("socket://*").
Defined in [CLDC]

socket

Low Level Net Access

javax.microedition.io.
SocketProtocolPermission("socket://").
Defined in [CLDC]

server socket (without host)

Low Level Net Access

javax.microedition.io.
SSLProtocolPermission("ssl://*").
Defined in [CLDC]

ssl

Low Level Net Access

javax.microedition.io.
CommProtocolPermission("comm:*").
Defined in [CLDC]

comm

Local Connectivity

javax.microedition.io.PushRegistryPermission("*", "static,dynamic,alarm").

All

Application Auto Invocation

javax.microedition.io.IMCProtocolPermission("imc://*")

imc

Local Connectivity

Table 8-5 collects permissions that are not mapped to any function group and sets access level for Clients. Permissions indicated as Permitted are granted to application suites as shown in the Table. Permissions indicated as Not Permitted are those that MUST NOT be mapped to any function group, and MUST NOT be available if not explicitly permitted by the policy defined in the Security Protection Domain associated with the Client.

Table 8-5 : Permissions Not Mapped To Function Groups

Permission

Assigned to a trusted Client

Assigned to the "Untrusted" Client

java.util.PropertyPermission
("microedition.deviceid.*", "read").
See java.lang.System.getProperty(). Defined in [CLDC].

Permitted

Not Permitted

java.util.PropertyPermission
("microedition.subscriberid.*", "read").
See java.lang.System.getProperty(). Defined in [CLDC].

Permitted

Not Permitted

java.util.PropertyPermission
("microedition.locale", "read").
See java.lang.System.getProperty(). Defined in [CLDC].

Permitted

Permitted

java.util.PropertyPermission
("microedition.profile", "read").
See java.lang.System.getProperty(). Defined in [CLDC].

Permitted

Permitted

java.util.PropertyPermission
("microedition.platform", "read").
See java.lang.System.getProperty(). Defined in [CLDC].

Permitted

Permitted

java.util.PropertyPermission
("microedition.*", "read"), covers all "microedition.*" system properties not indicated above.
See java.lang.System.getProperty(). Defined in [CLDC].

Permitted

Permitted

javax.microedition.event.EventPermission
("*", "read")

Permitted Permitted

javax.microedition.event.EventPermission
("*", "register")

Permitted Permitted

javax.microedition.event.EventPermission
("*", "post")

Permitted Not Permitted

javax.microedition.event.EventPermission
("*", "postsystem")

Permitted Not Permitted

javax.microedition.io.HttpProtocolPermission("http://localhost");
javax.microedition.io.HttpsProtocolPermission("https://localhost");
javax.microedition.io.SocketProtocolPermission("socket://localhost");

Defined in [CLDC].
Permitted Not Permitted

javax.microedition.swm.SWMPermission
("manageSuite")

Permitted Not Permitted

javax.microedition.swm.SWMPermission
("installation")

Permitted Not Permitted

javax.microedition.swm.SWMPermission
("manageTask")

Permitted Not Permitted

javax.microedition.cellular.CellularPermission
("subscriber")

Permitted Not Permitted

javax.microedition.cellular.CellularPermission
("cellularNetwork")

Permitted Not Permitted

javax.microedition.power.PowerStatePermission
("set")

Permitted Not Permitted

javax.microedition.power.PowerStatePermission
("setUrgent")

Not Permitted Not Permitted

java.lang.RuntimePermission
("exitVM"). See java.lang.Runtime.exit() and java.lang.System.exit(). Defined in [CLDC].

Not Permitted Not Permitted

java.lang.RuntimePermission
("modifyThread"). See java.lang.Thread.checkAccess(). Defined in [CLDC].

Not Permitted Not Permitted

java.lang.RuntimePermission("*"). See java.lang.Thread.checkAccess(). Defined in [CLDC].

Not Permitted Not Permitted

javax.microedition.midlet.AutoStartPermission

Not Permitted Not Permitted

Auto Invocation And Push Registry Security Requirements

The PushRegistry is the primary Auto Invocation mechanism subject to the security policy.

The PushRegistry is protected using the security framework and permissions. The application suite must have the javax.microedition.io.PushRegistryPermission to register an alarm based launch, to register dynamically using the PushRegistry, or to make a static registration in the application descriptor.

The push mechanism uses protocols in which the device is acting as the server and connections can be accepted from other elements of the network. To use the push mechanisms the application suite will need the permission to use the server connection in addition to the {@code PushRegistryPermission}. For example, to register a program that can be started via push might use the following attributes in the manifest:

    MIDlet-Push-1: socket://:79, com.oracle.example.Sample, *
    MIDlet-Permissions-1: javax.microedition.io.PushRegistryPermission "socket:" "static,dynamic"
    MIDlet-Permissions-2: javax.microedition.io.SocketProtocolPermission "socket://"
    

Requirements on Restricted APIs

When permission is granted to a function group, this action effectively grants access to all individual permissions that have been requested under this function group. An implementation MUST guarantee that a SecurityException is thrown when the caller has not been granted the appropriate security permissions. If an application uses the capabilities defined in this and other APIs, the following rules MUST apply:

Mobile Media Client Policy

The permissions needed to deploy the [JSR 135] APIs are defined in the Multimedia Security Addendum to JSR 135 Mobile Media API, version 1.2 of [JSR 135].

Implementations MUST ensure that I/O access from the Mobile Media API follows the same security requirements as the Generic Connection Framework, as specified in the package documentation for javax.microedition.io. Example methods include javax.microedition.media.Player.start, javax.microedition.media.Player.prefetch, etc. When these methods are used to fetch the content for the player via an HTTP connection, the implementation MUST enforce the security requirements specified for HTTP and HTTPS.

Application Download and Execution While Roaming and After Changing the Smart Card

All previously authorized and installed application suites MUST act in accordance with the policy defined in the Security Protection Domain associated with this Client when the device is roaming, or when the device smart card is changed.

Newly downloaded application suites are authenticated to a Client currently available either on the device or at the specified location on the smart card (for example, SIM, USIM or WIM) and are authorized in accordance with the security policy.

If device roaming or a smart card change causes a failure to access network resources that the application was previously authorized to access, then the implementation MUST NOT throw a SecurityException. This failure is not related to application suite authorization, so the implementation MUST throw an IOException instead.

If an application suite cannot be executed due to a smart card change, the implementation MUST NOT delete the application suite. In case of a trial to execute the application suite without a successful authentication, a SecurityException MUST be thrown.