h06301 s 00001/00005/00256 d D 1.6 00/09/22 16:03:44 courtney 7 6 c Moved assertion concerning security checks to overview. c e s 00009/00008/00252 d D 1.5 00/09/16 17:08:09 courtney 6 5 c [4366884] Clarifed that SecurityManager.checkPermission is used, unless c otherwise specified. c e s 00024/00015/00236 d D 1.4 00/07/27 19:25:50 courtney 5 4 c Fixed errors in example code. c e s 00025/00027/00226 d D 1.3 00/07/26 17:34:16 courtney 4 3 c Added assertion that Java TV API methods that check security permissions c always do so through SecurityManager.checkPermission(Permission). c c Changed code example to check permissions appropriately. c c e s 00212/00210/00041 d D 1.2 00/02/07 17:55:38 billf 3 1 c Typographical fixes. e s 00000/00000/00000 d R 1.2 70/01/01 00:00:02 Codemgr 2 1 c SunPro Code Manager data about conflicts, renames, etc... c Name history : 2 1 src/doc-files/security.html c Name history : 1 0 src/security.html e s 00251/00000/00000 d D 1.1 00/01/14 03:06:43 billf 1 0 c Added security document e u U f e 0 t T I 1 I 3
I 4 E 4Java's security model addresses permitting or denying access to resoruces, based on the source of the code requesting access. It is a tried and proven architecture that has benefited from years of experience. In computer workstations and personal computers, the "source" from which code comes is, generally speaking, determined by the site from which the code is downloaded (often a URL), or by a trusted signer who has signed the code.
The Java security model is readily applicable to interactive television, and provides clear benefits. It allows a responsible party to reliably prevent classes of code from accessing resources that the code shouldn't need access to. For example, an advertising application can be pervented from changing the channel to a network owned by the advertiser, an application can be granted access to select only certain services (such as those within a bouquet), an application can be prevented from accessing the return channel, or it can be denied access to a users' in-home network. Providing a simple, reliable mechanism to deny such access provides important benefits, including cost reductions, particularly in a horizontal market.
It can be argued that applications could be exhaustively tested to ensure that they don't misbehave. We believe that such testing is expensive and difficult. The Java security model frees the broadcaster from some of this kind of testing, by allowing it to establish a "sandbox" that constrains the actions of applications; the Java 2 security model allows that sandbox to be easily configurable, so that it can be expanded to fit the needs of a given application.
In the Java 2 security model, permissions are expressed as subclasses of java.security.Permission. A method that detects the violation of a security constraint does so by throwing a java.lang.SecurityException. This is a subclass of java.lang.RuntimeException, but despite this, it is required that any method of the Java TV extension that can exit due to a SecurityException document this fact by:
E 3 I 3The Java language's security model is readily applicable to interactive television and provides clear benefits. It allows a responsible party to reliably prevent classes of code from accessing resources that the code shouldn't need access to. For example, an advertising application can be prevented from changing the channel to a network owned by the advertiser, an application can be granted access to select only certain services (such as those within a bouquet), an application can be prevented from accessing the return channel, or it can be denied access to a users' in-home network. Providing a simple, reliable mechanism to deny such access provides important benefits, including cost reductions, D 4 particularly in a horizontal market. E 4 I 4 particularly in a horizontal market. E 4
It can be argued that applications could be exhaustively tested to ensure that they don't misbehave. However, such testing is expensive and difficult. The Java language's security model frees the broadcaster from some of this testing, by allowing it to establish a "sandbox," which constrains the actions of applications; the Java 2 Platform, Standard Edition (J2SE), security model allows that sandbox to be easily configurable so D 4 it can be expanded to fit the needs of a given application. E 4 I 4 it can be expanded to fit the needs of a given application. E 4
In the J2SE security model, permissions are expressed as subclasses of java.security.Permission. A method that detects the violation of a security constraint does so by throwing a java.lang.SecurityException. This is a subclass of java.lang.RuntimeException, but despite D 4 this, any method of the Java TV API that can exit due to a SecurityException must document this fact by: E 4 I 4 this, any method of the Java TV API that can exit due to a SecurityException must document this fact by: E 4 E 3
The Java 2 security model is described in depth in the book "Inside Java 2 Platform Security" by Li Gong, ISBN 0-201-31000-7.
For a horizontal market, we recommend that the underlying platform security be based on the Java 2 security model. The Java TV extension API might, however, be applied in certain vertical markets that have modest security requirements. For platforms such as this, the permission classes described below will be considered optional if the underlying platform does not support the Java 2 security architecture. For all platforms that support Java 2 security, the permission classes are a required part of the Java TV extension.
E 3 I 3A natural question that arises is "who is the responsible party that is allowed to assign permissions?" The Java TV vertical extension API does not demand one single answer to this question, because the answer depends on the business model underlying each individual interactive television platform. In a closed network where the set top box is owned E 3 I 3
For a horizontal market, the underlying platform D 4 security should be based on the J2SE security model. The Java TV API might, E 4 I 4 security should be based on the J2SE security model. The Java TV API might, E 4 however, be applied in certain vertical markets that have modest security requirements. For platforms such as this, the permission classes described below will be considered optional if the underlying platform does not support the J2SE security architecture. For all platforms that support the J2SE security model, the permission classes are a required part of the Java TV API.
In a closed network where the set-top box is owned E 3 by the network operator, the responsible party would likely be the network D 3 operator. In a horizontal market, the answer is less clear; we make the following observations and recommendations:
E 3 I 3 operator. In a horizontal market, the answer is less clear, given the following considerations: E 3
E 3 I 3
E 3 I 3
E 3 I 3
E 3 I 3
The Java TV extension does not dictate any one answer to the polciy underlying permission setting. The model for who is trusted and who assigns permissions is an important part of the business model underlying a complete platform for interactive television. The Java technologies provide support for a variety of signing models, but it is ultimately up to the body that specifies the complete platform to determine the model for granting permissions.
E 3 D 3In this section, we discuss the permissions that exist for the Java TV vertical extension APIs. In addition to these permissions, there are the permissions that exist in the underlying Java platform, and permissions for any other APIs that are defined as part of a complete platform.
In Java TV, many resources are accessed with a Locator. Locators are used to:
E 3 I 3In the Java TV API, many resources are accessed with a Locator. Locators are used to: E 3
In many ways, a Locator is analagous to a filename in a computer filesystem. In computers, a filename is often associated with a hardware device, such as a printer and the screen ("prn:" and "con:" in DOS-based systems, and /dev/lp* and /dev/tty in Unix systems). Associating permissions with files is a well-established mechanism for restricting E 3 I 3 In many ways, a Locator is analogous to a file name in a computer file system. In computers, a file name is often associated with a hardware device, such as a printer and the screen ("prn:" and "con:" in DOS-based systems, and /dev/lp* and /dev/tty in UNIX systems). Associating permissions with files is a well established mechanism for restricting E 3 access to data files, hardware devices, and other resources in computer D 3 systems.
The Java model for access to a filesystem is twofold: There is a file object (java.io.File), which represents the path to an object in the filesystem, and there is a security check based on that name. In the Java 2 security model, that security check is reified in the class java.io.FilePermission. A FilePermission contans a path (or a regular expression denoting a set of paths), and an action string. The action string can be read, write, execute or delete. In the 1.1 security model, the same facility is exposed through a small number of check methods on java.lang.SecrityManager (checkRead(String), etc.).
The FilePermission object allows access to a set of files based on a wildcarding mechanism. A set of FilePermission objects may be combined to give any desired degree of access. For example, it is straightforward to construct a set of two permissions that gives code read-write access to one directory, and read-only access to a different directory. FilePermission is described in detail in "Inside Java 2 Platoform Security" section 3.6.4.
A mechanism similar to FilePermission is ideally suited to the needs of recources that are accessed via locators. For example, consider the following set of permissions for an application:
E 3 I 3 D 4 systems. E 4 I 4 systems. E 4The Java language model for access to a file system is twofold: There is a file object (java.io.File), which represents the path to an object in the file system, and there is a security check D 4 based on that name. In the J2SE security model, that security check is E 4 I 4 based on that name. In the J2SE security model, that security check is E 4 reified in the class java.io.FilePermission. A FilePermission contains a path (or a regular expression denoting a set of paths), and an action string. The action string can be read, write, execute or delete. In the JDK 1.1 security model, the same facility is exposed through a small number of check methods on java.lang.SecrityManager (checkRead(String), D 4 etc.). E 4 I 4 etc.). E 4
The FilePermission object allows access to a set of files based on a wildcarding mechanism. A set of FilePermission objects may be combined to give any desired degree of access. For example, it is straightforward to construct a set of two permissions that gives code read-write access to one directory, and read-only access to a different directory. FilePermission is described in detail in Inside D 4 Java 2 Platform Security, section 3.6.4. E 4 I 4 Java 2 Platform Security, section 3.6.4. E 4
A mechanism similar to FilePermission is ideally suited to the needs of resources that are accessed via Locators. For example, consider the following set of permissions for an application: E 3
This is analagous to the kinds of access that FilePermission grants. For this reason, important permissions in the Java TV extension have a Locator in their constructor. Using a Locator in this way does not place any requirements on the internal representation an implementation maintains for a locator. It does, however, imply a requirement on the signalling of permissions. Namely, a permission that relates to a given locator needs to be signalled in such a way that the permission object can determine if it grants access for a given locator. A signalling specification would probably define some kind of wildcarding scheme based on paths for locators, to facilitate the natural expression of a set of permissions. For example, the locator for a service might have a representation equivalent to "/service/physical/channel007" or "/service/logical/ESPN/TheDeuce". Doing so would allow logical wildcarding in the signalling of permissions.
The JavaTV API does not mandate any particular format for locators. This is something that must be specified as part of a complete platform. Despite this, an application running on a platform that implements the Java 2 security model can test whether or not it has access to the resource corresponding to a given locator, with code like the following:
E 3 I 3 This is analogous to the kinds of access that FilePermission grants. For this reason, important permissions in the Java TV API have a Locator in their constructor. Using a Locator in this way does not place any requirements on the internal representation an implementation maintains for a Locator. It does, however, imply a requirement on the signaling of permissions. Namely, a permission that relates to a given Locator needs to be signaled in such a way that the permission object can determine if it grants access for a given Locator. A signaling specification would probably D 4 define some kind of wildcarding scheme based on paths for Locators, to E 4 I 4 define some kind of wildcarding scheme based on paths for Locators, to E 4 facilitate the natural expression of a set of permissions. For example, the Locator for a service might have a representation equivalent to "/service/physical/channel007" or "/service/logical/ESPN/TheDeuce". Doing so would allow logical wildcarding D 4 in the signaling of permissions. E 4 I 4 in the signaling of permissions. E 4The Java TV API does not mandate a particular D 4 format for Locators. This format must be specified as part of a complete E 4 I 4 format for Locators. This format must be specified as part of a complete E 4 platform. Despite this, an application running on a platform that implements the J2SE security model can test whether or not it has access to the resource D 5 corresponding to a given Locator using code similar to the following:
boolean hasAccessTo(Locator l) { Permission p = new javax.tv.mumble.MumblePermission(l); boolean allowed = true; try { D 4 java.security.AccessController.checkPermission(p); E 4 I 4 System.getSecurityManager.checkPermission(p); E 4 } catch (java.security.AccessControlException ex) { allowed = false; } return allowed; }D 4 E 4 I 4
Note that methods in the Java TV API
that check security permissions always do so by calling SecurityManager.checkPermission(Permission
perm).
E 5
I 5
corresponding to a given Locator using code similar to the following:
boolean hasAccessTo(Locator l) {
D 6
boolean allowed = true;
SecurityManager m = System.getSecurityManager();
E 6
I 6
boolean allowed =
true;
SecurityManager m = System.getSecurityManager();
E 6
if (m != null) {
Permission p = new javax.tv.mumble.MumblePermission(l);
try {
m.checkPermission(p);
} catch (SecurityException ex) {
allowed = false;
D 6
}
}
E 6
I 6
}
}
E 6
return allowed;
D 6
}
Note that methods in the Java TV API that
check security permissions always do so by calling SecurityManager.checkPermission(Permission
p).
E 6
I 6
}
D 7
Note that,
unless otherwise specified, methods in the Java TV API that check
security permissions do so by calling
SecurityManager.checkPermission(Permission p).
E 7
I 7
E 7
E 6
E 5
E 4
E 3
D 3 boolean hasAccessTo(Locator l) { Permission p = new javax.tv.mumble.MumblePermission(l); boolean allowed = true; try { java.security.AccessController.checkPermission(p); } catch (java.security.AccessControlException ex) { allowed = false; } return allowed; }E 3 I 3
Copyright © 2000 Sun Microsystems, Inc.E 3 E 1