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.
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. |
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. |
|
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. |
The basic authorization of an application suite is established by the relationships between the following elements:
A protection domain consisting of a set of Permissions.
A set of Permissions requested by the application suite in
MIDlet-Permission-<n>
,
MIDlet-Permission-Opt-<n>
,
MIDlet-Permissions
, and
MIDlet-Permissions-Opt
attributes
Application do not need to be aware of the security policy except for security exceptions that may occur when using APIs.
An application suite is subject to a single protection domain and its permissible actions.
The internal representation of protection domains may be implementation specific.
The details of how authentication results and configuration settings are presented to the user in a user interface (if any) are implementation dependent and are outside the scope of this specification.
The device must protect the security policy and protection domain information stored in the device from modification except by authorized parties.
Security policy allows an implementation to restrict access
but MUST NOT be used to avoid implementing functionality. For
example, unimplemented protocols under the Generic Connection
framework MUST throw ConnectionNotFoundException
.
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 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.
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.
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 :
Classname
– the fully qualified name
of a subclass of java.security.Permission
.
The Classname
is required.
For example, javax.microedition.io.HttpProtocolPermission
.
Name
– the name of the protected resource.
The Name
is required if the Classname
constructor requires one or more arguments.
For example, http://server/index.html
.
Action
– the action(s) requested.
The Action
field is required if the Classname
constructor requires two or more arguments.
The Action
value must contain one or more actions
as specified by second argument of the constructor of
Classname
.
For example, in a java.util.PropertyPermission
,
the action read
.
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:
MIDlet-Permission-Opt-<n>
requested that is not critical to the application suite,
if either the Permission is not in the domain or the Permission
class can not be found, then the attribute is ignored.
For each remaining MIDlet-Permission-<n>
, if a
constructor with the appropriate number of arguments cannot be
found or is inaccessible or the arguments supplied would fail the
static requirements of the constructor, then the installation
MUST fail.
If the Permission class has only a one argument constructor, then
it is an error to supply the Action
field.
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-Opt
attributes.
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.
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:
MIDlet-Permission-<n>
,
MIDlet-Permission-Opt-<n>
,
MIDlet-Permissions
, and
MIDlet-Permissions-Opt
attributes.
MIDlet-Permission-Opt-<n>
attributes,
if either the Permission is not in the domain or the Permission class
can not be found, then the attribute is ignored.
Then each permission in the protection domain
with the same permission class is compared with the requested permission
to select the least privileged permission.
If the requested permission is implied by the protection domain
then the requested permission is granted to the application suite.
If not, then if the protection domain permission is implied by
the requested permission then the domain policy permission is granted
to the application suite.
If neither permission implies the other then neither is granted to
the application suite.
MIDlet-Permissions-Opt
attribute, if any of
the requested permissions are unknown to the device, they are
removed from the requested permissions.
MIDlet-Permission-<n>
attributes,
the Permission.implies
methods are used to check
that some Permission in the domain "implies" each requested
permission. Each requested permission that is implied by the
domain policy is granted to the application suite.
MIDlet-Permissions
attribute, if any of
the requested permissions are unknown to the device, then the
application suite MUST NOT be installed or invoked.
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"; } |
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.
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.
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 :
java.security.Permission
optionally followed
by arguments for name and action.
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://*”; } |
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.