Just An Application

June 15, 2009

What’s New In MIDP 3.0 ? Part 9: Fine-Grained Permissions

Filed under: Java, JME, MIDP, MIDP Security, MIDP3, Security — Tags: , , , , , , — Simon Lewis @ 2:01 pm

The introduction of support for the JSE fine-grained permission security model in CLDC 1.1.1 (JSR139) has enabled MIDP 3
to modify the existing MIDP 2 permission model by substituting fine-grained permissions for the named permissions used previously.

1. Permission Classes

The JSE fine-grained permission security model is based on the definition of permission classes, that is, Java classes which inherit directly or indirectly from the class java.security.Permission. The model is programmatic and hence extensible both in terms of how a security policy is defined and enforced, and in terms of the semantics of permissions and how they can be parameterized.

The most common parameterizations of permission classes are those enable the specification of the set of entities to which they apply, and in some cases, in addition, the set of actions on those entities which the permission grants, but essentially arbitrary parameterization and permission semantics is possible as long as someone is prepared to write the code.

The MIDP 3 security model uses the permission classes defined in either CLDC 1.1.1 or CDC in conjunction with MIDP 3 specific permission classes it defines itself.

Note

The permission classes defined in the CLDC 1.1.1 version of the javax.microedition.io package currently have no counterparts in the CDC version of the package. It is not clear what the implications of this are for MIDP 3 running on top of CDC and MIDlet Suites/LIBlets targetted at CDC.

1.1 CLDC 1.1.1 Permission Classes

1.1.1 java.lang

RuntimePermission

A RuntimePermission controls access to runtime thread modification and vm exit.

The permission is parameterized by identifying the functionality to control. The possible values are the Strings

    "exitVM"

or

    "modifyThread"

or

    "*"

which matches all possible values.

There are no defined actions. The permission is either granted or denied.

1.1.2 java.util

PropertyPermission

A PropertyPermission controls access to a system property or properties.

It is parameterized on the name of the system property or system properties, to which it controls access, and on the actions which may be performed.

The system property or system properties can be specified by name, using a pattern, or as a wildcard which matches all properties.

The possible actions are specified as read or write. These allow the methods System.getProperty(String) and System.setProperty(String) respectively, to be called.

Note

It is unclear why the write action is defined as the method System.setProperty(String) does not exist in CLDC.

To successfully call System.getProperty(String) for a given property, the caller must have been granted a PropertyPermission which allows the read action for that property specifically, for a set of properties which includes that property, or for all properties.

1.1.3 javax.microedition.io

The javax.microedition.io package contains permission classes which control the opening of connections via the variants of the Connector.open(). method. Permission classes are defined on a per-connection URI scheme basis as follows.

Scheme Class
comm CommProtocolPermission
datagram DatagramProtocolPermission
file FileProtocolPermission
http HttpProtocolPermission
https HttpsProtocolPermission
socket SocketProtocolPermission
ssl SSLProtocolPermission

All the permission classes are parameterized on the set of connections they allow to be opened. The specification of the set of permitted connections is protocol specific, but in the case of the IP based protocols, for example, permitted hosts and/or ports or port ranges can be specified.

The FileProtocolPermission supports additional parameterization of the file access mode granted.

1.2.2 MIDP 3.0 Permission Classes

MIDP 3.0 augments the permission classes defined in CLDC 1.1.1 or CDC with permission classes for controlling access to MIDP specific functionality.

1.2.2.1 javax.microedition.event

EventPermission

An EventPermission controls runtime access to the functionality provided by the Events API. See here for details.

Note

The specification only specifies the use of EventPermission at runtime. I would assume it is also intended to be used to control the installation time registration of Event Handlers.

1.2.2.2 javax.microedition.io

PushRegistryPermission

A PushRegistryPermission controls access to the PushRegistry functionality, both at installation time
and runtime.

The permission is parameterized in terms of the URI scheme of the push connections to which it applies,
and the actions that are granted on those push connections.

The URI specifies the scheme to which the permission applies, and must be of the form

    <scheme> ":"

Alternatively the wildcard (“*”) which matches all URI schemes can be specified.

The actions which can be specified are

  • alarm
  • dynamic
  • static

which control

  • the runtime registration of alarms
  • the runtime registration of push connections
  • the installation time registration of push connections

respectively.

When requesting permission to register alarms the URI must be specified as “*”.

1.2.2.3 javax.microedition.midlet

ActionsDeniedPermission

The ActionsDeniedPermission controls the installation time use of the following attributes

  • MIDlet-UserDenied
  • MIDlet-&ltn>-UserDenied

The permission is not parameterized. It is either granted or denied. If the MIDlet Suite being installed is granted the permission then use of the attributes is allowed, otherwise it is not and installation of the MIDlet Suite will fail.

AutoStartPermission

The AutoStartPermission controls the installation time declaration of AutoStart MIDlets via the use of the

  • MIDlet-<n>-Type

attribute. The permission is not parameterized. It is either granted or denied. If the MIDlet Suite being installed is granted the permission then the attribute can be used to declare an AutoStart MIDlet, otherwise it cannot, and installation of the MIDlet Suite will faill.

1.2.3 Permission Classes For Other JSRs

Existing JSRs which currently define named permissions for use with MIDP 2.0+ will need to be updated to define equivalent permission classes for use with MIDP 3.0.

In some cases this is already happening. For example the proposed changes for the Maintenance Release of the Content Handler API (JSR211) include the definition of a ContentHandlerPermission class.

2. Installation Time Changes

2.1 MIDlet Suite Permissions

MIDlet Suites that need to do so must now request each required or optional permission at installation time using either a

    MIDlet-Permission-<n>

or a

    MIDlet-Permission-Opt-<n>

attribute respectively. The standard constraints for attribute name ordinals apply.

The value in each case is of the form

    <ClassName> [" " <Name> [" " <Actions>]]

The <ClassName> is the name of the permission class.

The <Name> identifies the entity or entities to which the permission applies, and is a quoted string.

The <Actions> are a whitespace separated list of the requested actions as specified for the given permission class. Each action is a quoted string.

The <Actions> can only be omitted if the specified permission class has a one argument constructor.

The <Name> and <Actions> can only be omitted if the specified permission class has a zero argument constructor.

As in MIDP 2, if any required permission specified by the MIDlet Suite is denied by the protection domain to which it would be bound if installed then the installation will fail.

A MIDP 3.0 MIDlet Suite must not use the MIDP 2 attributes MIDlet-Permissions and MIDlet-Permissions-Opt. Installation will fail if either of them is present.

Example

An attribute for a MIDlet Suite that needs to register AutoStart MIDlets.

    MIDlet-Permission-1: javax.microedition.midlet.AutoStartPermission

Example

An attribute for a MIDlet Suite that would like to be able to listen for datagrams on port 45000

    MIDlet-Permission-Opt-1: javax.microedition.io.DatagramProtocolPermission "datagram://:45000"

Example

An attribute for a MIDlet Suite that needs to listen for, get, and register event handlers for, all events.

    MIDlet-Permission-1: javax.microedition.event.EventPermission "*" "read" "register"

2.2 LIBlet Permissions

A LIBlet may specify its required and optional permissions in its JAD and the manifest of its Jar using

    LIBlet-Permission-<n>

and

    LIBlet-Permission-Opt-<n>

attributes respectively. The standard constraints for attribute name ordinals apply.

The values are as for the corresponding MIDlet Suite attributes.

The specification of a permission via a LIBlet-Permission-<n> or LIBlet-Permission-Opt-<n> attribute in a LIBlet which a MIDlet Suite is dependent upon is not equivalent to its specification via a MIDlet-Permission-<n> or MIDlet-Permission-Opt-<n> attribute in the MIDlet Suite itself. It does not constitute a request for a permission on behalf of the dependent MIDlet Suite. Instead a MIDlet Suite must specify all the required and optional permissions of all the LIBlets it is dependent upon itself using MIDlet-Permission-<n> or MIDlet-Permission-Opt-<n> attributes as appropriate.

Note

The specification does not require an implementation to check whether a MIDlet Suite has in fact requested all the permissions specified in the LIBlets it is dependent upon. The onus is on the MIDlet Suite developer to get it right, or to use a tool to generate the necessary MIDlet Suite attributes programatically given the LIBlet dependencies.

3. Runtime Changes

1.5.1 Permission Checking

In MIDP 2.0 runtime checking of named permissions could be performed using a MIDlet’s

     checkPermission(String)

method. This method has been deprecated. It will continue to work as before if called by a legacy MIDlet, but will otherwise throw a IllegalStateException.

Runtime permission checking can now be performed by using the method

    java.security.AccessController.checkPermission(Permission)

A fundamental and important difference between these two methods is their behaviour in the case of checking a user permission when determining the status would require interaction with a user.

Calling the MIDlet.checkPermission(String) method in this case will cause the method to return a status of -1, meaning unknown.

Calling the AccessController.checkPermission(Permission) method in case this will result in the user being prompted. It will then either return or throw a SecurityException as appropriate.

It is difficult to think of a situation in which this is actually desirable, and the specification goes as far as to say

… it is advised that MIDlets do not check permissions unless absolutely necessary.

Example


...

import java.security.AccessController;

import javax.microedition.io.PushRegistryPermission;

...

    // See if we can dynamically register socket based push connections
    try
    {
        AccessController.checkPermission(
                            new PushRegistryPermission(
                                    "socket:",
                                    "dynamic"));
        // Apparently so
        ...
    }
    catch (SecurityException se)
    {
        // Nope
        ...
    }

1.5.2 Newly Protected APIs

1.5.2.1 java.lang

1.5.2.1.1 Runtime

The method Runtime.exit() is now protected by a java.lang.RuntimePermission. Since MIDP has always specified that this method must throw a SecurityException when invoked by a MIDlet the behaviour is effectively unchanged.

1.5.2.1.2 System

The method System.exit() is now protected by a java.lang.RuntimePermission. Since MIDP has always specified that this method must throw a SecurityException when invoked by a MIDlet the behaviour is effectively unchanged.

The method System.getProperty(String) is now protected by a java.util.PropertyPermission.

Depending upon the system property or properties it is accessing a legacy MIDlet using this method may no longer work correctly.

A new MIDlet using this method will need to request the appropriate permission(s).

1.5.2.1.3 Thread

The methods Thread.interrupt() and Thread.setProperty(int) are now protected by a RutimePermission.

Should there be any legacy MIDlets using either of these methods they will no longer work correctly.

4. Backwards Compatibility

4.1 Installation Time

To support existing MIDP 2 MIDlet Suites that request named permissions, the specification defines a mapping from named permissions to corresponding permission classes and parameters.

In addition the specification requires an implementation to support the use of the MIDlet-Permission-<n> and MIDlet-Permission-Opt-<n> by a MIDlet Suite which has declared its required profile to be MIDP 2.0 or 2.1.

If these attributes are present and the MIDP 2 attributes MIDlet-Permissions and/or MIDlet-Permissions-Opt are also present, the MIDP 2 attributes will be ignored and the MIDP 3 attributes will be used instead.

If only the MIDP 2 attributes are present they will be used and the requested named permissions will be mapped to the corresponding permission classes and parameters using the defined mapping.

Note

I assume this is intended to make it possible to retrofit existing MIDP 2 MIDlet suites to request fine-grained permissions but otherwise leave them unchanged.

4.2 Runtime

As mentioned above the method MIDlet.checkPermission(String) has been deprecated. Legacy MIDlets can of course continue to call it. Its argument will be mapped to the corresponding permission class and attributes.

Also as mentioned above a handful of methods are now protected permissions. The specification does not contain any specific requirements regarding their behaviour when called by legacy MIDlets, so it is possible that a legacy MIDlet may break as a result. The most obvious candidate to cause problems is System.getProperty(String).


Copyright (c) 2009 By Simon Lewis. All Rights Reserved.

Advertisements

5 Comments »

  1. […] MIDlets should use the java.security.AccessController.checkPermission(Permission) method to perform permission […]

    Pingback by What’s New In MIDP 3.0 ? Part 11: javax.microedition.midlet.MIDlet « Just An Application — June 16, 2009 @ 2:14 pm

  2. […] To declare the type of a MIDlet as autostart a MIDlet Suite must be granted the javax.microedition.midlet.AutoStartPermission. […]

    Pingback by What’s New In MIDP 3.0 ? Part 13: MIDlet Types « Just An Application — June 18, 2009 @ 4:05 pm

  3. […] To specify a MIDlet-<n>-UserDenied attribute or attributes a MIDlet Suite must have been granted the ActionsDeniedPermission. […]

    Pingback by What’s New In MIDP 3.0 ? Part 17: Preventing Users From Starting And Stopping MIDlets « Just An Application — June 19, 2009 @ 6:28 pm

  4. […] access any of these properties a MIDlet will need to be granted the PropertyPermission with an action of read and a name matching the name of the property being […]

    Pingback by What’s New In MIDP 3.0 ? Part 45: Accessing Device And Subscriber Specific Properties « Just An Application — July 31, 2009 @ 6:06 pm


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: