7.5 Java Security


Running programs on an iTV receiver typically gives that program access to certain receiver resources. The Java security framework was designed to control that access. The original security model introduced by JDK 1.0 is the sandbox model, explicitly listing of all operations controlled by the security framework. Within that framework, the security manager is responsible for determining which operations are allowed.

The JDK 1.0 security model relied on the assumption that Java applications could be fully trusted. Subsequent versions of the JDK extended the security framework with trust model and PKI infrastructure. Specifically, JDK 1.1 introduced the Java Cryptography Architecture (JCA) which introduces a trust model relying on digital signatures. JDK 1.2 introduced a fine-grained access control mechanism. Java 2 platform, also known as J2EE, introduced the notion of protection domains, the notion of guarded objects, call tree permission checks, and the ability to reenable privileged operations. Control is achieved through the use of AccessControllers , ProtectionDomains , CodeSources , Permissions , GuardedObjects , implemented by the Java packages listed in Table 7.5.

Table 7.5. Java Security Packages

Package

Description

java.security

The basic set of classes and interfaces for the security framework. This package supersedes the java.security.acl package.

java.security.interfaces

Provides interfaces for generating RSA (Rivest, Shamir, and Adleman AsymmetricCipher algorithm) keys.

java.security.cert

Enables parsing and managing certificates.

java.security.spec

Contains classes and interfaces for specifications of keys and algorithm parameters.

7.5.1 Permission Classes

Permission classes encapsulate individual permissions requested or granted. They can be set to read-only and made immutable. They can be aggregated using PermissionCollection and Permissions classes. Permissions granted to a ProtectionDomain , also called privileges, associated with that domain; there is no separate privilege class.

  • FilePermission permission subclass : FilePermission enables control of read, write, execute, and delete permissions needed to access and manipulate local files and directories. Typically, this permission distinguishes between transient and persistent file systems. It enables specifying path patterns pointing to files, directories, or combinations of both. For example, it enables specifying access permissions to all the files in a directory recursively.

  • SocketPermission permission subclass : SocketPermission enables the operations of accept, connect, listen, resolve. Typically, this permission does not make a distinction between TCP, UDP, unicast and multicast sockets. It is associated with a host name , such as localhost, or a Host IP address; groups can be specified by selecting, for example, all hosts in a domain using "*.domain", or all hosts using "*". Also supported is the notion of port ranges, which enables specifying a single port number, all ports above a certain number, all ports under a certain port number, as well as all ports between two port numbers .

  • PropertyPermission permission subclass : PropertyPermission enables reading and writing attributes of execution environment variables via the Toolkit's getProperty() and setProperty() methods . A target patterns is used to specify the attribute owner, supporting both specific targets or target patterns. This permission should be granted to every JavaTV Xlet that needs to customize its behavior to best fit the target platform.

  • RuntimePermission permission subclass : RuntimePermission enables invocation to createClassLoader() , getClassLoader() , setSecurityManager() , exitVM() , and other similar methods. Typically, this permission should never be granted to JavaTV Xlets, and only be granted to middleware code authorized by the middleware manufacturer.

  • AllPermission permission subclass : This is a special class that enables avoiding enumeration of all the permissions. It is particularly useful when the list of all permissions is implicit, or, when it is extensible and unknown until execution time.

7.5.2 JavaTV Permissions

  • MediaSelectPermission : The javax.tv.media.MediaSelectPermission class represents permission to select, via MediaSelectControl, the content that a JMF Player presents . A caller might not have permission to select content referenced by some locators.

  • ReadPermission : The javax.tv.service.ReadPermission represents permission to read the data referenced by a given Locator.

  • SelectPermission : The javax.tv.service.selection.SelectPermission represents permission to perform a select() operation on a ServiceContext . A caller might have permission to select some content but not others.

  • ServiceContextPermission : The javax.tv.service.selection.Service-ContextPermission represents permission to control a ServiceContext . A ServiceContextPermission contains a name and an actions string. The target name is the name of the service context permission (see Table 7.6). Each permission identifies a method. A wildcard match is signified by an asterisk, i.e., "*". The actions string is either "own" or "*". From a security standpoint, a caller is said to "own" a ServiceContext instance if it was acquired through ServiceContextFactory .createServiceContext() or ServiceContextFactory.getService-Context(javax.tv.xlet.XletContext) . See Table 7.6 for ServiceContextPermission target names and associated permissions.

Table 7.6. List of ServiceContextPermission Targets

Permission Target Name

What the Permission Allows

access()

Access to a ServiceContext , via ServiceContext-Factory.getServiceContexts()

create()

Creation of a ServiceContext

destroy()

Destruction of a ServiceContext

getServiceContentHandlers()

Obtaining the service content handlers from a ServiceContext

stop()

Stopping a ServiceContext

The permission ServiceContextPermission("access","*") is intended to be granted only to special monitoring applications and not to general broadcast Xlets. When undefined target and actions strings are provided to the constructor, subsequent calls to SecurityManager.checkPermission() with the resulting SelectPermission object will fail.



ITV Handbook. Technologies and Standards
ITV Handbook: Technologies and Standards
ISBN: 0131003127
EAN: 2147483647
Year: 2003
Pages: 170

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net