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 or LIBlet 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 or LIBlet 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:
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 a single Client, a LIBlet to one or more Clients. How an application suite or LIBlet is assigned to a Client depends on the Security Authentication Provider used by this implementation. Application suites or LIBlets that cannot be authenticated as per the Security Framework MUST be assigned to a predefined "Untrusted" Client. This is only true if they declare themselves as being untrusted. In case they pretend to be trusted and authentication fails, they MUST NOT be installed at all.
If application suites can be identified via more than one way, they will be assigned to a single Client as well. How it is decided to which Client they will get assigned inthis case, is implementation-dependent. If LIBlets can be identified via more than one way, they will be assigned to all resulting Clients.
Each LIBlet that is a dependency of one or more applications MUST be assigned to each Client any of those applications is assigned to, or to the privileged "Root" or "root" Client, otherwise the installation of the respective application suite will fail. The set of Clients used during provisioning (if supported) is used 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.
Application suites and LIBlets that do not try to be authenticated will be assigned to a virtual "Untrusted" Client. As mentioned in the description of the Security Trust Model it is up to the Authentication Provider to determine how restrictive the access to protected APIs or functions is.
The "Untrusted" Client for untrusted application suites and LIBlets MUST generally allow access to the following packages (if available) though:
Table 8-1 : Packages Allowed for the "Untrusted" Client |
|
---|---|
API (if supported by the implementation) |
Description |
|
RMS APIs |
|
Application Lifecycle APIs |
|
Audio Media APIs (only playing) |
The Security Policy Provider is free to make more functionality available for untrusted applications or LIBlets, it is in the responsibility of the implementor to estimate and consider the risks caused by that.
The Security Policy Provider is free to define a special Root client. The words "Root" and "root" are handled as reserved names for a client and must not be used by any other client as defined by third party or using explicit means of definition (like in a policy file).
The purpose of the Root Client is that the Authentication Provider can assign application suites or LIBlets (if supported) to it, which opens unlimited permissions for the respective applications and LIBlets. In particular, a LIBlet assigned to the Root client can be used by any application without the need of assigning this LIBlet to the Client the application is assigned, which would be necessary without having assigned the LIBlet to the Root client.
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.
The high level functions essentially capture and reflect the actions and consequences of the underlying individual permissions. These so-called function groups are used in MEEP 8 only to make permission declarations more comprehensive and open a possibility to group permissions belonging to the same "kind" of activities. The usage of the groups is optional. The following function groups are pre-defined:
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 can be defined.
If a new function group is added, it should not introduce any redundancy to the existing groups.
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. |
http |
Net Access |
javax.microedition.io. |
https |
Net Access |
javax.microedition.io. |
datagram |
Low Level Net Access |
javax.microedition.io. |
datagram server (without host) |
Low Level Net Access |
javax.microedition.io. |
socket |
Low Level Net Access |
javax.microedition.io. |
server socket (without host) |
Low Level Net Access |
javax.microedition.io. |
ssl |
Low Level Net Access |
javax.microedition.io. |
comm |
Local Connectivity |
javax.microedition.io.PushRegistryPermission("*", "static,dynamic,alarm"). |
All |
Application Auto Invocation |
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 |
Permitted |
Not Permitted |
java.util.PropertyPermission |
Permitted |
Not Permitted |
java.util.PropertyPermission |
Permitted |
Permitted |
java.util.PropertyPermission |
Permitted |
Permitted |
java.util.PropertyPermission |
Permitted |
Permitted |
java.util.PropertyPermission |
Permitted |
Permitted |
javax.microedition.event.EventPermission |
Permitted | Permitted |
javax.microedition.event.EventPermission |
Permitted | Permitted |
javax.microedition.event.EventPermission |
Permitted | Not Permitted |
javax.microedition.event.EventPermission |
Permitted | Not Permitted |
javax.microedition.io.HttpProtocolPermission("http://localhost"); |
Permitted | Not Permitted |
javax.microedition.swm.SWMPermission |
Permitted | Not Permitted |
javax.microedition.swm.SWMPermission |
Permitted | Not Permitted |
javax.microedition.swm.SWMPermission |
Permitted | Not Permitted |
javax.microedition.swm.SWMPermission |
Permitted, but not recommended | Not Permitted |
javax.microedition.swm.SWMPermission |
Permitted, but not recommended | Not Permitted |
javax.microedition.swm.SWMPermission |
Permitted, but not recommended | Not Permitted |
javax.microedition.cellular.CellularPermission |
Permitted | Not Permitted |
javax.microedition.cellular.CellularPermission |
Permitted | Not Permitted |
Permitted | Not Permitted | |
javax.microedition.power.PowerStatePermission |
Not Permitted | Not Permitted |
java.lang.RuntimePermission |
Not Permitted | Not Permitted |
java.lang.RuntimePermission |
Not Permitted | Not Permitted |
java.lang.RuntimePermission("*"). See java.lang.Thread.checkAccess(). Defined in [CLDC]. |
Not Permitted | Not Permitted |
Not Permitted | Not Permitted |
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 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-Permission-1: javax.microedition.io.PushRegistryPermission "socket:" "static,dynamic" MIDlet-Permission-2: javax.microedition.io.SocketProtocolPermission "socket://" |
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:
All the external API functions that need to be protected by the security framework MUST have permissions defined in those JSRs, and follow the naming rules identified in this specification.
The functions that are not deemed security-protected by specification can be accessed explicitly by untrusted application suites, as per general security rules.
If an external API does not define permissions for security-protected functions because the API specification is released earlier than IMP-NG, access is granted even to any functions that relate to network access.
All Licensee Open Classes (aka LOC, aka OEM Specific Classes, proprietary packages that do not logically fall into the category of a Java ME configuration, profile, or optional package) MUST adhere to the permission framework as defined in this document.
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.
All previously authorized and installed application suites and LIBlets 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 or LIBlets 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.
Copyright (c) 2014, Oracle and/or its affiliates. All rights reserved.