This chapter discusses security with the Oracle Java ME Embedded environment. Note that with version 8 of the OJMEE, the security system was changed considerably, and now uses Java SE-style fine-grain permissions. In addition, a security policy must be chosen and JAR files, if applicable, must be digitally signed in order for peripherals to be accessed.
Applications that require access to peripherals or resources must request appropriate permissions in the JAD file. For more information on using the Device I/O APIs, please see the Device I/O API 1.1 specification and the associated Javadocs at the following site:
Table 3-1 gives a list of all permissions that can be requested in the Oracle Java ME Embedded environment, as well as a description of when they are applicable.
Table 3-1 Oracle Java ME Embedded Permissions
Permission | Description |
---|---|
|
Allows access to the keystore |
|
Allows access to a DTLS server. |
|
Allows remote update of the Java ME Embedded runtime. |
|
Accessing files |
|
Accessing runtime properties |
|
Use of log files |
|
Accessing system properties |
|
Access to smartcards using the APDU protocol |
|
Use of cellular telephone functionality on a board. |
|
Reading and posting system-level events |
|
Use of access points for network connections. |
|
Use of the COMM serial port protocol |
|
Use of a Cell Broadcast Service (CBS) Connector |
|
Use of a file read Connector |
|
Use of a file write Connector |
|
Use of a real-time streaming protocol (RTSP) Connector |
|
Use of an SMS Connector |
|
Use of the datagram protocol |
|
Use of the Datagram Transport Layer Security (DTLS) protocol |
|
Use of a file protocol |
|
Use of the HTTP protocol |
|
Use of the HTTPS protocol |
|
Use of the Inter-MIDlet communication protocol |
|
Use of a multicast protocol |
|
Use of a push registry |
|
Use of a socket protocol |
|
Use of the Secure Sockets Layer (SSL) protocol |
|
Obtain the current location |
|
Use of a recording feature on the device |
|
Use of a video snapshot feature on the device |
|
A permission to autostart an IMlet suite on a device |
|
Access the current power state of the device |
|
Access the software management features of the Java ME Embedded runtime |
|
Receive a Cell Broadcast Service (CBS) message |
|
Receive an SMS message |
|
Send an SMS message |
|
Use of analog-to-digital converter (ADC) |
|
Use of AT communication line |
|
Use of the hardware counter |
|
Use of digital-to-analog converter (DAC) |
|
Opening of any Device I/O peripheral. |
|
Use of generic Device I/O connections |
|
Use of a General Purpose I/O (GPIO) pin |
|
Use of a General Purpose I/O (GPIO) port |
|
Use of the I2C bus on the board |
|
Use of the Memory-Mapped I/O (MMIO) capabilities on the board |
|
Use of the Pulse Width Modulation (PWM) capabilities on the board |
|
Use of the SPI bus on the board |
|
Use of the UART bus on the board |
|
Use of the watchdog timer on the board |
Applications that require access to Device I/O APIs must request appropriate permissions in JAD files. For more information on using the Device I/O APIs, please see the Device I/O API 1.1 specification and the associated Javadocs at the following site:
First, the JAD file must have the proper API permissions. Here is how to sign the application both in NetBeans and without an IDE.
In NetBeans, right-click the project name and choose Properties. Select Application Descriptor, then in the resulting pane, select API Permissions. Click the Add... button, and add the appropriate permissions, as shown in Figure 3-1. Click OK to close the project properties dialog.
Figure 3-1 Adding Permissions Using the NetBeans IDE
If you are not using an IDE, you can manually modify the application descriptor file to contain the following permissions.
MIDlet-Permission-1: com.oracle.dio.DeviceMgmtPermission "*:*" "open"
The NetBeans IDE enables developers both to sign the applications with a local certificate and upload the certificate on the device. See the appropriate Getting Started Guide for your embedded platform to learn how to use the NetBeans IDE to sign your application.
Signing applications using a command line is the preferred route for applications that are widely distributed. Here are the instructions on how to setup a keystore with a local certificate that can be used to sign the applications:
This method allows to bypass a certificate check and execute unsigned applications as if they were signed and given all requested permissions. This method should be used only for development and debugging. Final testing must be done using a real certificate as described in method #1.
To use NullAuthenticationProvider
, set the following property in the jwc_properties.ini
file on the board:
[internal] authentication.provider = com.oracle.meep.security.NullAuthenticationProvider
Note that the Java runtime must not be running when editing the jwc_properties.ini
file.
The following permissions are available that affect the use of portions of the CLDC libraries.
The java.io.FilePermission
controls access to a file or directory. A FilePermission
consists of a pathname and a set of actions that are valid for the resource specified by that pathname.
The resource name is simply the pathname of the file or directory granted the specified actions. A pathname that ends in "/*
" (where "/
" is the file separator character, File.separatorChar
) indicates all the files and directories contained in that directory. A pathname that ends with "/-
" indicates all files and all recursive subdirectories contained in that directory. A pathname consisting of the special token "<<ALL FILES>>
" matches any file.
Note:
A pathname need not have a leading "/
". A pathname consisting of a single "*
" indicates all the files in the current directory, while a pathname consisting of a single "-
" indicates all the files in the current directory and recursively all files and subdirectories contained in the current directory.
Table 3-5 shows the actions can be requested with this permission, as a list of comma-separated keywords:
Table 3-2 FilePermission Actions
Value | Meaning |
---|---|
|
Read permission |
|
Write permission |
|
Execute permission |
|
Permission to delete the resource |
|
Read a link permission. This is retained for SE compatibility but is not currently used. |
The java.lang.RuntimePermission
represents runtime permissions. A RuntimePermission
contains a resource name, but no actions list.
The resource name is the name of the runtime permission. The naming convention follows the hierarchical property naming convention. Also, an asterisk may appear at the end of the name, following a ".
", or by itself, to signify a wildcard match. For example: "loadLibrary.*
" and "*
" signify a wildcard match, while "*loadLibrary
" and "a*b
" do not.
Table 3-3 shows the possible runtime permissions that are allowed, as well as their effects and possible risks of using them.
Table 3-3 RuntimePermission Actions
Value | Effect | Risks |
---|---|---|
|
Halting of the Java Virtual Machine (JVM) with the specified exit status |
This allows an attacker to mount a denial-of-service attack by automatically forcing the virtual machine to halt. Note that the " |
|
Setting of the security manager (possibly replacing an existing security manager) |
The security manager is a class that allows applications to implement a security policy. Granting the |
|
Creation of a new security manager |
This gives code access to protected, sensitive methods that may disclose information about other classes or the execution stack. |
|
Setting of |
This allows changing the value of the standard system streams. An attacker may set |
|
Modification of threads, possibly via calls to perform thread interrupts, or |
This allows an attacker to modify the behavior of any thread in the system. |
The java.util.logging.LoggingPermission
is a permission which the security manager will check when code that is running with a security manager calls one of the logging control methods, such as Logger.setLevel()
.
Currently there is only one over-arching LoggingPermission
, without resources or actions. This permission simply grants the ability to control the logging configuration, for example by adding or removing handlers, by adding or removing filters, or by changing logging levels.
The java.util.PropertyPermission
is for general Java property permissions.
The resource name is the name of the property (for example, "java.home
" or "os.name
"). The naming convention follows the hierarchical property naming convention. Also, an asterisk may appear at the end of the name, following a ".
", or by itself, to signify a wildcard match. For example: "java.*
" and "*
" signify a wildcard match, while "*java
" and "a*b
" do not.
Table 3-4 shows the actions can be requested with this permission, as a list of comma-separated keywords:
Table 3-4 PropertyPermission Actions
Value | Meaning |
---|---|
|
Read permission |
|
Write permission |
Care should be taken before granting code permission to access certain system properties. For example, granting permission to access the "java.home
" system property gives potentially malevolent code sensitive information about the system environment, such as the Java installation directory. Also, granting permission to access the "user.name
" and "user.home
" system properties gives potentially malevolent code sensitive information about the user environment, including the user's account name and home directory.
The following permissions are available that allow access to the Java ME keystore.
The com.oracle.crypto.keystore.KeyStorePermission
controls the type of access allowed to the key store.
Table 3-5 shows the resource names that can be requested with this permission:
Table 3-5 KeyStorePermission Resource Names
Value | Meaning |
---|---|
|
Access to client certificates only |
|
Access to the entire certificate storage. |
The following are among the more common permissions that can be requested from most Oracle Java ME Embedded devices, depending on whether the functionality is supported by the underlying board. See the Getting Started Guide for your embedded board to determine which Device I/O permissions and resources are available for use.
The jdk.dio.adc.ADCPermission
class defines permissions for Analog-to-Digital channel access on an embedded board.
The resource name is a numerical channel number. Refer to the Getting Started Guide of your embedded board to determine which channel numbers are available for ADC control.
Table 3-6 shows the actions can be requested with this permission:
Table 3-6 ADCPermission Actions
Value | Meaning |
---|---|
|
The requested channel is opened and available for use. |
|
Manage the power saving mode of a device. |
The jdk.dio.atcmd.ATPermission
class defines permissions AT device access.
The resource name is a numerical channel number. Refer to the Getting Started Guide of your embedded board to determine which channels are available for AT control.
Table 3-7 shows the actions can be requested with an ATPermission
:
Table 3-7 ATPermission Actions
Value | Meaning |
---|---|
|
Open AT functions |
|
Open data connections |
|
Manage the power saving mode of a device. |
The jdk.dio.counter.CounterPermission
class defines permissions for pulse counter access.
The resource name is a numerical channel number. Refer to the Getting Started Guide of your embedded board to determine which channels are available for pulse counter control.
Table 3-8 shows the actions can be requested with an ATPermission
:
Table 3-8 CounterPermission Actions
Value | Meaning |
---|---|
|
Open and access pulse counter functions |
|
Manage the power saving mode of a device. |
The jdk.dio.dac.DACPermission
class defines permissions for Digital-to-Analog channel access on an embedded board.
The resource name is a numerical channel number. Refer to the Getting Started Guide of your embedded board to determine which channel numbers are available for DAC control.
Table 3-9 shows the actions can be requested with this permission:
Table 3-9 DACPermission Actions
Value | Meaning |
---|---|
|
The requested channel is opened and available for use. |
|
Manage the power saving mode of a device. |
The jdk.dio.DeviceMgmtPermission
class defines permissions for registering and un-registering devices as well as opening devices using their registered configurations.
The resource name is a combination of a device name and of a device ID or range of device IDs. It takes the following form:
{device-name-spec} [ ":
"{device-id-spec} ]
{device-name-spec}
The {device-name-spec} string takes the following form:
{device-name} | "*
" | ""
The {device-name} string is a device name that is returned by a call to DeviceDescriptor.getName()
.
A {device-name-spec} specification consisting of the asterisk ("*
") matches all device names. A {device-name-spec} specification consisting of the empty string ("") designates an undefined device name that may only be matched by an empty string or an asterisk.
{device-id-spec}
The {device-id-spec} string takes the following form:
{device-id} | "-
"{device-id} | {device-id}"-"[{device-id}] | "*
"
The {device-id} string is a device ID that is returned by a call to DeviceDescriptor.getID()
. Note that the characters in the string must all be decimal digits.
A {device-id-spec} specification of the form "n-
" (where n is a device ID) signifies all device IDs numbered n and above, while a specification of the form "-
n" indicates all device IDs numbered n and below. A single asterisk in the place of the {device-id-spec} field matches all device IDs.
The name "*:*
" matches all device names and all device IDs, as is the name "*
".
Table 3-10 shows the actions can be requested with this permission:
Table 3-10 DeviceMgmtPermission Actions
Value | Meaning |
---|---|
|
Open a device using its device name or ID |
|
Register a new device. |
|
Un-register a new device |
The jdk.dio.generic.GenericPermission
class defines permissions for generic device access on an embedded board.
The resource name is a numerical channel number. Refer to the Getting Started Guide of your embedded board to determine which channel numbers are available for generic devices.
Table 3-11 shows the actions can be requested with this permission:
Table 3-11 GenericPermission Actions
Value | Meaning |
---|---|
|
The requested channel is opened and available for use. |
|
Manage the power saving mode of a generic device. |
The jdk.dio.gpio.GPIOPinPermission
class defines permissions for General Purpose I/O (GPIO) pin access on an embedded board.
The resource name is a numerical pin number. Refer to the Getting Started Guide of your embedded board to determine which pin numbers are available for GPIO control.
Table 3-12 shows the actions can be requested with this permission:
Table 3-12 GPIOPinPermission Actions
Value | Meaning |
---|---|
|
The requested channel is opened and available for use. |
|
Request permission to change the GPIO pin direction |
|
Manage the power saving mode of a GPIO pin. |
The jdk.dio.gpio.GPIOPortPermission
class defines permissions for General Purpose I/O (GPIO) port access on an embedded board. A GPIO port is made up of several (typically eight) GPIO pins.
The resource name is a numerical port number. Refer to the Getting Started Guide of your embedded board to determine which port numbers are available for GPIO control.
Table 3-13 shows the actions can be requested with this permission:
Table 3-13 GPIOPortPermission Actions
Value | Meaning |
---|---|
|
The requested channel is opened and available for use. |
|
Request permission to change the GPIO port direction |
|
Manage the power saving mode of a GPIO port. |
The jdk.dio.i2cbus.I2CPermission
class defines permissions for I2C bus access on an embedded board.
The resource name is a channel number. Refer to the Getting Started Guide of your embedded board to determine which channel numbers are available for I2C control.
Table 3-14 shows the actions can be requested with this permission:
Table 3-14 I2CPermission Actions
Value | Meaning |
---|---|
|
The requested channel is opened and available for use. |
|
Manage the power saving mode of an I2C bus. |
The jdk.dio.mmio.MMIOPermission
class defines permissions for MMIO bus access on an embedded board.
The resource name is a memory-address (in hexadecimal format) returned by a call to MMIODeviceConfig.getAddress()
. The characters in the string must all be hexadecimal digits. Refer to the Getting Started Guide of your embedded board to determine which addresses are available for MMIO use.
Table 3-15 shows the actions can be requested with this permission:
Table 3-15 MMIOPermission Actions
Value | Meaning |
---|---|
|
The requested channel is opened and available for use. |
|
Manage the power saving mode of an MMIO bus. |
The jdk.dio.pwm.PWMPermission
class defines permissions for Pulse Width Modulation (PWM) channel access on an embedded board.
The resource name is a numerical channel number. Refer to the Getting Started Guide of your embedded board to determine which channel numbers are available for PWM control.
Table 3-16 shows the actions can be requested with this permission:
Table 3-16 PWMPermission Actions
Value | Meaning |
---|---|
|
The requested channel is opened and available for use. |
|
Manage the power saving mode of a device. |
The jdk.dio.spibus.SPIPermission
class defines permissions for SPI bus access on an embedded board.
The resource name is a channel number. Refer to the Getting Started Guide of your embedded board to determine which channel numbers are available for SPI control.
Table 3-17 shows the actions can be requested with this permission:
Table 3-17 SPIPermission Actions
Value | Meaning |
---|---|
|
The requested channel is opened and available for use. |
|
Manage the power saving mode of an SPI bus. |
The jdk.dio.uart.UARTPermission
class defines permissions for UART bus access on an embedded board.
The resource name is a channel number. Refer to the Getting Started Guide of your embedded board to determine which channel numbers are available for UART control.
Table 3-18 shows the actions can be requested with this permission:
Table 3-18 UARTPermission Actions
Value | Meaning |
---|---|
|
The requested channel is opened and available for use. |
|
Manage the power saving mode of an UART bus. |
The jdk.dio.watchdog.WatchdogTimerPermission
class defines permissions for the watchdog timer on an embedded board.
The resource name is a channel number. Refer to the Getting Started Guide of your embedded board to determine which channel number is available for the watchdog timer.
Table 3-19 shows the actions can be requested with this permission:
Table 3-19 WatchdogTimerPermission Actions
Value | Meaning |
---|---|
|
The requested channel is opened and available for use. |
|
Manage the power saving mode of the watchdog timer.. |
The following permission allows access to smart cards on Java ME embedded devices.
The javax.microedition.apdu.APDUPermission
class represents access to a smart card using the APDU protocol. An APDUPermission
contains a resource name (also called a target name) but no actions list. The target name is the symbolic name of the APDUPermission
.
The resource name can be one of two items, as shown in Table 3-20.
Table 3-20 APDUPermission Target Names
Target Name | Permission Allows |
---|---|
|
The ability to communicate with a smart card application identified by an AID target. |
|
The ability to communicate with a (U)SAT application on channel 0. |
The following permissions deal with embedded devices that can connect to a cellular network.
The javax.microedition.cellular.CellularPermission
class defines permissions for cellular network resources on an embedded board. It consists only of a resource name.
The resource name can be one of three items, as shown in Table 3-21.
Table 3-21 CellularPermission Resource Names
Resource | Meaning |
---|---|
|
Resources that access or modify the cellular subscriber identity, which is often recorded on a SIM, R-UIM, or CSIM. |
|
Resources that access the cellular network. |
|
All available cellular resources. |
The following permissions deal with generic events that can be sent from the underlying runtime operating system to the Oracle Java ME Embedded runtime.
The javax.microedition.event.EventPermission
class defines permissions that allow applications to receive events from the underlying runtime operating system.
The resource name is the name of the event, such as "BATTERY_LEVE
L" or "com.MyCompany.MyEvent
". The naming convention follows a hierarchical property naming convention. Also, an asterisk may appear at the end of the name, following a ".
", or by itself, to signify a wildcard match. For example, "com.MyCompany.*
" or "*
" is valid, while "*MyCompany
" or "a*b
" is not valid.
The actions to be granted are a list of comma-separated keywords. The possible keywords are "post
", "postsystem
", "read
" and "register
". Table 3-22 gives more details on these keywords.
Table 3-22 EventPermission Actions
Value | Meaning |
---|---|
|
Permission to post an event. |
|
Permission to post a system event. To see which system events are supported, call |
|
Permission to read an event. |
|
Permission to register and un-register applications to launch in response to events. |
The following permissions deal with embedded devices that can use a COMM protocol through a serial port.
The javax.microedition.io.CommProtocolPermission
class defines permissions for COMM resources on an embedded board. It consists only of a resource name.
The resource name is a base connection string and is typically formatted as:
comm:
<port identifier>[<optional parameters>]
An exact BNF grammar for the COMM protocol URI is given in Table 3-23.
Table 3-23 CellularPermission Resource Names
Resource | Meaning |
---|---|
base connection string |
" |
<port_id> |
A non-empty case-sensitive string of alphanumeric characters |
<wildcarded_port_id> |
All available cellular resources. |
<options_list> |
*(<baud_rate_string>| <bitsperchar>| <stopbits>| <parity>| <blocking>| <autocts>| <autorts>) |
<baud_rate_string> |
" |
<baud_rate> |
non-empty string of digits |
<bitsperchar> |
" |
<bit_value> |
" |
<stopbits> |
" |
<stop_value> |
" |
<parity> |
" |
<parity_value> |
" |
<blocking> |
" |
<autocts> |
" |
<autorts> |
" |
<on_off> |
" |
The following permissions deal with those associated with the javax.microedition.io.Connector
class, a factory class for creating new Connection objects.
The javax.microedition.io.Connector.cbs
defines permissions for cellular broadcast service.
The resource name is a channel number. Refer to the Getting Started Guide of your embedded board to determine which channel number is available for the CBS.
Table 3-24 shows the actions can be requested with this permission:
Table 3-24 Connector CBS Actions
Value | Meaning |
---|---|
|
The requested channel is opened and available for use. |
|
Manage the power saving mode of the CBS.. |
The javax.microedition.io.Connector.file.read
defines permissions for connections that read files.
The resource name is a channel number. Refer to the Getting Started Guide of your embedded board to determine which channel number is available for reading files.
Table 3-25 shows the actions can be requested with this permission:
Table 3-25 Connector File Read Actions
Value | Meaning |
---|---|
|
The requested channel is opened and available for use. |
|
Manage the power saving mode of the file read.. |
The javax.microedition.io.Connector.file.write
defines permissions for connections that write files.
The resource name is a channel number. Refer to the Getting Started Guide of your embedded board to determine which channel number is available.
Table 3-26 shows the actions can be requested with this permission:
Table 3-26 WatchdogTimerPermission Actions
Value | Meaning |
---|---|
|
The requested channel is opened and available for use. |
|
Manage the power saving mode of the file write.. |
The javax.microedition.io.Connector.rtsp
defines permissions for connections that use the real-time streaming protocol (RTSP).
The resource name is a channel number. Refer to the Getting Started Guide of your embedded board to determine which channel number is available.
Table 3-27 shows the actions can be requested with this permission:
Table 3-27 WatchdogTimerPermission Actions
Value | Meaning |
---|---|
|
The requested channel is opened and available for use. |
|
Manage the power saving mode of the RTSP.. |
The javax.microedition.io.Connector.sms
defines permissions for SMS messaging.
The resource name is a channel number. Refer to the Getting Started Guide of your embedded board to determine which channel number is available for SMS.
Table 3-28 shows the actions can be requested with this permission:
Table 3-28 WatchdogTimerPermission Actions
Value | Meaning |
---|---|
|
The requested channel is opened and available for use. |
|
Manage the power saving mode of the SMS.. |
The following permissions deal with embedded devices that can use datagram protocols.
The javax.microedition.io.DatagramProtocolPermission
class represents access rights to connections via the Datagram protocol. A DatagramProtocolPermission
consists of a URI string, but no actions.
The URI string specifies a connection for sending and receiving datagrams. It takes the following general form:
datagram://
{host}:{portspec} | datagram
://
[:
{portspec}]
The value of the {host} field must be a symbolic hostname, a literal IPv4 address or an IP-literal as specified by RFC 3986. An IP-literal requires an IPv6Address to bew surrounded with square brackets ([]
). Note that IPvFuture addresses from RFC 3986 are not currently supported.
The {host} field is omitted to indicate an inbound, server-mode connection. Server-mode URIs may also omit the {portspec} field to request a system-assigned port number. In such a case, the DatagramProtocolPermission
is normalized to the equivalent URI: datagram://:1024-65535
.
If the {host} string is a DNS name, an asterisk may appear in the left-most position to indicate a match of 1 or more entire domain labels. Partial domain label matches are not permitted. For example, "*.oracle.com
" is valid, but "*oracle.com
" is not. An asterisk by itself matches all hosts in outbound, client-mode connections.
The {portspec} string takes the following form:
portnumber | -
portnumber | portnumber-
[portnumber] | "*
"
A {portspec} of the form "n-
" (where n is a port number) signifies all ports numbered n and above, while a specification of the form "-
n" indicates all ports numbered n and below. A single asterisk in the place of the {portspec} field matches all ports. Therefore, the URI "datagram://:*
" matches server-mode datagram connections to all ports, and the URI "datagram://*:*
" matches client-mode datagram connections to all hosts on all ports.
The javax.microedition.io.DTLSProtocolPermission
class represents access rights to connections that use the Datagram Transport Layer Security (DTLS) protocol. A DTLSProtocolPermission
consists of a URI string but no actions list.The URI string specifies a connection for sending and receiving datagrams. It takes the following general form:
dtls://
{host}:
{portspec} The value of the {host} field must be a symbolic hostname, a literal IPv4 address or an IP-literal as specified by RFC 3986. An IP-literal requires an IPv6Address to be surrounded with square brackets ([]
). Note that IPvFuture addresses from RFC 3986 are not supported.
If the {host} string is a DNS name, an asterisk may appear in the left-most position to indicate a match of 1 or more entire domain labels. Partial domain label matches are not permitted. For example, "*.oracle.com
" is valid, but "*oracle.com
" is not. An asterisk by itself matches all hosts in outbound, client-mode connections.
The {portspec} string takes the following form:
portnumber | -
portnumber | portnumber-
[portnumber] | "*
"
A {portspec} of the form "n-
" (where n is a port number) signifies all ports numbered n and above, while a specification of the form "-
n" indicates all ports numbered n and below. A single asterisk in the place of the {portspec} field matches all ports. Therefore, the URI "dtls://*:*
" matches client-mode datagram connections to all hosts on all ports.
The javax.microedition.io.DTLSServerPermission
class represents access rights to server connections via the the Datagram Transport Layer Security (DTLS) protocol protocol. A DTLSServerPermission
consists of a URI string but no actions list. The URI string specifies a connection for sending and receiving datagrams. It takes the following general form:
dtls://:
{portspec}
The exact syntax for the DTLSSrverPermission
URI is provided by this BNF.
The {portspec} string takes the following form:
portnumber | -
portnumber | portnumber-
[portnumber] | "*
"
A {portspec} of the form "N-
" (where N is a port number) signifies all ports numbered N and above, while a specification of the form "-
N" indicates all ports numbered N and below. A single asterisk in the place of the {portspec} field matches all ports. Therefore, the URI "dtls://*
" matches secure-mode secure datagram connections to all ports.
The following permissions deal with embedded devices that can use files.
The javax.microedition.io.FileProtocolPermission
class represents access rights to connections via the "file" protocol. A FileProtocolPermission
consists of a URI string indicating a fully-qualified, absolute pathname as well as a set of actions desired for that pathname.
The URI string takes the following general form:
file://
[{host}]{absolute_path} | file:
{absolute_path}
The exact syntax is given by RFCs 1738 and 2396. In addition, a pathname that ends in "/*
" matches all the files and directories contained in that directory. A pathname that ends with "/-
" recursively matches all files and subdirectories contained in that directory.
In addition to the syntax defined by RFC 1738, FileProtocolPermission
must accept and normalize URIs of the form file:
{abs_path}. If {host} is omitted, it is equivalent to using localhost
. Also, note that {absolute_path} follows the syntax defined for {fpath} in RFC 1738.
Table 3-29 shows the actions can be requested with this permission. Note that multiple actions can be requested by separating keywords with commas.
Table 3-29 FileProtocolPermission Actions
Value | Meaning |
---|---|
|
The file can be read from using the protocol. |
|
The file can be written to using the protocol. |
The following permissions deal with embedded devices that can use HTTP or HTTPS protocols.
The javax.microedition.io.HTTPProtocolPermission
class represents access rights to connections via the HTTP protocol. An HttpProtocolPermission
consists of a URI string, but no actions list.
The URI string specifies a data resource accessible via HTTP. It takes the following general form:
http://
{host}[:
{portspec}][{pathname}][?
{query}][#
{fragment}]
The value of the {host} field must be a symbolic hostname, a literal IPv4 address or an IP-literal as specified by RFC 3986. An IP-literal requires IPv6Address to be surrounded with square brackets ([]
). IPvFuture addresses from RFC 3986 are not supported.
If the {host} string is a DNS name, an asterisk may appear in the left-most position to indicate a match of one or more entire domain labels. Partial domain label matches are not permitted. For example, "*.oracle.com
" is valid, but "*oracle.com
" is not. An asterisk by itself matches all hosts.
The {portspec} string takes the following form:
portnumber | -portnumber | portnumber-
[portnumber] | *
| empty string
A {portspec} specification of the form "n-" (where n is a port number) signifies all ports numbered n and above, while a specification of the form "-n" indicates all ports numbered n and below. A single asterisk in the place of the {portspec} field matches all ports; therefore, the URI "http://*:*
" matches HTTP connections to all hosts on all ports. If the {portspec} field is omitted, default port 80 is assumed.
The javax.microedition.io.HTTPSProtocolPermission
class represents access rights to connections via the HTTPS protocol. A HttpsProtocolPermission
consists of a URI string, but no actions list.
The URI string specifies a data resource accessible via secure HTTPS. It takes the following general form:
http://
{host}[:
{portspec}][{pathname}][?
{query}][#
{fragment}]
The value of the {host} field must be a symbolic hostname, a literal IPv4 address or an IP-literal as specified by RFC 3986. An IP-literal requires IPv6Address to be surrounded with square brackets ([]
). IPvFuture addresses from RFC 3986 are not supported.
If the {host} string is a DNS name, an asterisk may appear in the left-most position to indicate a match of one or more entire domain labels. Partial domain label matches are not permitted. For example, "*.oracle.com
" is valid, but "*oracle.com
" is not. An asterisk by itself matches all hosts.
The {portspec} string takes the following form:
portnumber | -portnumber | portnumber-
[portnumber] | *
| empty string
A {portspec} specification of the form "n-" (where n is a port number) signifies all ports numbered n and above, while a specification of the form "-n" indicates all ports numbered n and below. A single asterisk in the place of the {portspec} field matches all ports; therefore, the URI "https://*:*
" matches HTTPS connections to all hosts on all ports. If the {portspec} field is omitted, default port 443 is assumed.
The following permissions deal with embedded devices that use the Inter-MIDlet Communication (IMC) protocol.
The javax.microedition.io.IMCProtocolPermission
class defines permissions for inter-MIDlet communication on an embedded board. IMC uses a low-level asynchronous bi-directional stream connection for communication between applications. The permission consists only of a resource name.
The resource name consists of a number of rules to create a base client connection string; these rules are shown in Table 3-30.
Table 3-30 IMCProtocolPermission Resource Name Rules
Rule | Meaning |
---|---|
Base client connection string |
" |
<Application UID> |
<Application suite vendor>" |
<Application suite vendor> |
:The application suite vendor |
<Application suite name> |
The application suite name |
<Application suite version> |
Formatted application suite version or wildcard character " |
<server name> |
IMC server name following the class naming syntax |
<server version> |
The version of the IMC server. Version backward compatibility is assumed.Versioning follows the format defined for the |
Note that in the first rule, the wildcard "*
" may be used instead of a specific <Application UID> when opening an IMC client connection. When the wildcard character is used, it allows the client to connect to any applications (even those from different vendors) if they all provide the same IMC service and meet the authorization requirements. However, which application's IMC server the client will be connected to is implementation specific.
The following permissions deal with embedded devices that use the multicast protocols.
The javax.microedition.io.MulticastProtocolPermission
class represents access rights to connections via the "multicast" protocol. A MulticastProtocolPermission
consists of a URI string but no actions list.
The exact syntax for the MulticastProtocolPermission
URI is provided by rules shown in Table 3-31.
Table 3-31 MulticastProtocolPermission Resource Name Rules
Rule | Meaning |
---|---|
base multicast connection string |
<inbound_connection> | <outbound_connection> |
<inbound_connection> |
" |
<outbound_connection> |
" |
<multicast_permission> |
" |
<host> |
<host name> | <ipaddr> |
<ipaddr> |
IPv4 address | ' |
<hostspec> |
<host> | " |
<auto_join> |
" |
<portspec> |
<portnumber> | <portrange> | " |
<portnumber> |
numeric port number |
<portrange> |
<portnumber> " |
The value of the {host} field must be a symbolic hostname, a literal IPv4 multicast address or a literal IPv6 address surrounded by square brackets ([]
), as specified by RFC 3986. The {hostspec} may be "*
" to allow connection to any multicast host group. The {hostspec} field may also be omitted to indicate an inbound, server-mode connection.
Server-mode URIs may also omit the <portspec> field to request a system-assigned port number. In such a case, the MulticastProtocolPermission
is normalized to the equivalent URI "multicast://:1024-65535
".
The <portspec> string takes the following form:
portnumber | -
portnumber | portnumber-
[portnumber] | "*
"
A <portspec> specification of the form "n-" (where n is a port number) signifies all ports numbered n and above, while a specification of the form "-n" indicates all ports numbered n and below. A single asterisk in the place of the <portspec> field matches all ports. Therefore, the URI "multicast://
<ipaddr>:
" matches multicast a host group to all ports, and the URI "multicast://*:*
" matches multicast connections to all host groups on all ports.
The following permissions deal with embedded devices that use push protocols.
The javax.microedition.io.PushRegistryPermission
class is used to check the static and dynamic registration of push connections and for registration of an alarm. The permission covers static registration via application attributes, and dynamic registration via PushRegistry.registerConnection(...)
and alarm registration with PushRegistry.registerAlarm()
.
For the purposes of Push Registration permission, the URI MUST consist only of the scheme and delimiter (":
") as defined by RFC-3986. The scheme may contain the wildcard character "*
", which allows registration of all schemes. For alarm registration, the URI is "*
" and the action is alarm. Push registration and alarm registration can be combined in a single permission. For example, the resource is "file:
" and the actions are "static,dynamic,alarm
".
Table 3-32 shows the actions can be requested with this permission. Note that multiple actions can be requested by separating keywords with commas.
Table 3-32 PushRegistryPermission Actions
Value | Meaning |
---|---|
|
Allows registration of a Push Connection in the packaging of the application suite |
|
Allows registration of a Push Connection using PushRegistry.registerConnection |
|
Allows registration of an alarm using PushRegistry.registerAlarm |
The following permissions deal with embedded devices that can use HTTP or HTTPS protocols.
The javax.microedition.io.SocketProtocolPermission
class represents access rights to connections via the "socket" protocol. A SocketProtocolPermission
consists of a URI string but no actions list.
The URI string specifies a socket stream connection. It takes the following general form:
socket://
{host}:
{portspec} | socket://
[:
{portspec}]
The exact syntax for the SocketProtocolPermission
URI is given by the grammar in Table 3-33.
Table 3-33 SocketProtocolPermission Resource Name Rules
Rule | Meaning |
---|---|
base socket connection string |
" |
<inbound_connection> |
" |
<outbound_connection> |
<host> " |
<host> |
<host name> | <ipaddr> | <wildcarded DNS> |
<ipaddr> |
IPv4 address | ' |
<wildcarded_DNS> |
" |
<domainlabel> |
internet domain label |
<portspec> |
<portnumber> | <portrange> | " |
<portnumber> |
numeric port number |
<portrange> |
<portnumber> " |
The value of the {host} field must be a symbolic hostname, a literal IPv4 address or an IP-literal with an IPv6Address as specified by RFC 3986. An IPv6Address must be surrounded with square brackets ([]
). Note that IPvFuture addresses are not currently supported.
The {host} field may be omitted to indicate a server-mode connection. Server-mode URIs may also omit the {portspec} field to indicate a system-assigned port number. In such a case, the SocketProtocolPermission
is normalized to the equivalent URI "socket://:1024-65535
".
If the {host} string is a DNS name, an asterisk may appear in the left-most position to indicate a match of one or more entire domain labels. Partial domain label matches are not permitted, therefore "*.oracle.com
" is valid, but "*oracle.com
" is not. An asterisk by itself matches all hosts in client-mode connections;
The {portspec} string takes the following form:
portnumber | "-
" portnumber | portnumber "-
" [portnumber] | "*
"
A {portspec} specification of the form "n-
" (where n is a port number) signifies all ports numbered n and above, while a specification of the form "-
n" indicates all ports numbered n and below. A single asterisk may be used in place of the {portspec} field to indicate all ports. Therefore, the URI "socket://:*
" matches server-mode socket connections to all ports, and the URI "socket://*:*
" matches client-mode socket connections to all hosts on all ports.
Note:
The syntax of URLs accepted by Connector.open()
for sockets differs from the syntax for SocketProtocolPermission
. In the socket:
protocol, the ":
" delimiter must always be present even if there is no port number, whereas the delimiter must not be present unless there is a port number in SocketProtocolPermission
.
The javax.microedition.io.SSLProtocolPermission
class represents access rights to connections that use the Secure Sockets Layer (SSL) protocol. A SSLProtocolPermission
consists of a URI string but no actions list.
The URI string specifies a secure socket stream connection. It takes the following general form:
ssl://
{host}:
{portspec} | ssl://
[:{portspec}]
The exact syntax for the SSLProtocolPermission
URI is given in Table 3-34.
Table 3-34 SSLProtocolPermission Resource Name Rules
Rule | Meaning |
---|---|
base SSL connection string |
" |
<inbound_connection> |
" |
<outbound_connection> |
<host> " |
<host> |
<host name> | <ipaddr> | <wildcarded DNS> |
<ipaddr> |
IPv4 address | ' |
<wildcarded_DNS> |
" |
<domainlabel> |
internet domain label |
<portspec> |
<portnumber> | <portrange> | " |
<portnumber> |
numeric port number |
<portrange> |
<portnumber> " |
The value of the {host} field must be a symbolic hostname, a literal IPv4 address or an IP-literal as specified by RFC 3986. An IPv6Address must be surrounded with square brackets ([]
). Note that IPvFuture addresses are not supported.
The {host} field is omitted to indicate a server-mode connection. Server-mode URIs may also omit the {portspec} field to indicate a system-assigned port number. In such a case, the SSLProtocolPermission
is normalized to the equivalent URI "ssl://:1024-65535
".
If the {host} string is a DNS name, an asterisk may appear in the left-most position to indicate a match of one or more entire domain labels. Partial domain label matches are not permitted, therefore "*.oracle.com
" is valid, but "*oracle.com
" is not. An asterisk by itself matches all hosts.
The {portspec} string takes the following form:
portnumber | -
portnumber | portnumber-
[portnumber] | "*
"
A {portspec} specification of the form "n-
" (where n is a port number) signifies all ports numbered n and above, while a specification of the form "-
n" indicates all ports numbered n and below. A single asterisk in the place of the {portspec} field matches all ports. Therefore, the URI "ssl://:*
" matches secure server connections to all ports, and the URI "ssl://*:*
" matches secure connections to all hosts on all ports.
The following permissions deal with embedded devices that have the ability to record or playback media.
The javax.microedition.media.RecordControl
class allows Java ME embedded applications to control audio recording on an embedded device. This permission consists of only the class, but no targets or actions.
The following permissions allow auto-start functionality on an embedded device.
The javax.microedition.midlet.AutoStartPermission
allows applications in an application suite to assume the auto-start application behavior.
Table 3-35 shows the names that are allowed with this permission.
Table 3-35 AutoStartPermission Actions
Value | Meaning |
---|---|
|
Auto-start of the application is allowed |
|
Auto-start of the application is not allowed |
The following permission allows applications to access the power state functionality of an embedded device.
The javax.microedition.power.PowerStatePermission
allows calls to PowerManager.setPowerState()
method.
Table 3-36 shows the names that are allowed with this permission.
Table 3-36 PowerStatePermission Actions
Value | Meaning |
---|---|
|
Calls to |
|
Calls to |
The following permissions allow applications to use of the software management (SWM) APIs on an embedded device.
The javax.microedition.power.SWMPermission
provides permission handling for SWM API permissions. An SWMPermission
object contains a resource and actions.
Table 3-37 shows the resource names that are allowed with this permission.
Table 3-37 SWMPermission Resource Names
Value | Meaning |
---|---|
|
Permission to perform the listed actions only for applications assigned to the same client |
|
Permission to perform the listed actions also for applications assigned to other clients. Usually this is a permission reserved for the root client. Granting this permissions to other clients should carefully considered to avoid security breaches. |
The actions to be granted are a list of comma-separated keywords, as shown in Table 3-38, as well as whether they are permitted on a trusted and non-trusted client.
Table 3-38 SWMPermission Actions
Name and Action | Assigned to Trusted Client | Assigned to Non-Trusted Client |
---|---|---|
|
Permitted |
Not Permitted. |
|
Permitted. |
Not Permitted. |
|
Permitted. |
Not Permitted. |
|
Permitted, but not recommended |
Not Permitted. |
|
Permitted, but not recommended |
Not Permitted. |
|
Permitted, but not recommended |
Not Permitted. |