Permissions in the Java Development Kit (JDK)

A permission represents access to a system resource. In order
for a resource access to be allowed for an applet (or an
application running with a security manager), the corresponding
permission must be explicitly granted to the code attempting the
access.

A permission typically has a name (often referred to as a
"target name") and, in some cases, a comma-separated list of one or
more actions. For example, the following code creates a
FilePermission object representing read access to the file named
abc in the /tmp directory:

perm = new java.io.FilePermission("/tmp/abc", "read");

In this, the target name is "/tmp/abc" and the
action string is "read".

Important Note: The above statement creates a permission
object. A permission object represents, but does not grant access
to, a system resource. Permission objects are constructed and
assigned ("granted") to code based on the policy in effect. When a
permission object is assigned to some code, that code is granted
the permission to access the system resource specified in the
permission object, in the specified manner. A permission object may
also be constructed by the current security manager when making
access decisions. In this case, the (target) permission object is
created based on the requested access, and checked against the
permission objects granted to and held by the code making the
request.

The policy for a Java application environment is represented by
a Policy object. In the "JavaPolicy" Policy
implementation, the policy can be specified within one or more
policy configuration files. The policy file(s) specify what
permissions are allowed for code from specified code sources. A
sample policy file entry that grants code from the
/home/sysadmin directory read access to the file
/tmp/abc is

For information about policy file locations and granting
permissions in policy files, see Default
Policy Implementation and Policy File Syntax. For information
about using the Policy Tool to specify the permissions, see
the Policy Tool documentation (for Solaris) (for Windows). Using the
Policy Tool saves typing and eliminates the need for you to
know the required syntax of policy files.

Technically, whenever a resource access is attempted, all
code traversed by the execution thread up to that point must have
permission for that resource access, unless some code on the thread
has been marked as "privileged." See API for Privileged Blocks for more
information about "privileged" code.

This document contains tables that describe the built-in JDK
permission types and discuss the risks of granting each permission.
It also contains tables showing the methods that require
permissions to be in effect in order to be successful, and for each
lists the required permission.

For more information about permissions, including the
superclasses java.security.Permission and
java.security.BasicPermission, and examples of
creating permission objects and granting permissions, see the
Security Architecture
Specification.

Permission Descriptions
and Risks

The following tables describe the built-in JDK permission types
and discuss the risks of granting each permission.

AllPermission

Note: Granting AllPermission should be done
with extreme care, as it implies all other permissions. Thus, it
grants code the ability to run with security disabled. Extreme
caution should be taken before granting such a permission to code.
This permission should be used only during testing, or in extremely
rare cases where an application or applet is completely trusted and
adding the necessary permissions to the policy is prohibitively
cumbersome.

SecurityPermission

A java.security.SecurityPermission
is for security permissions. A SecurityPermission
contains a name (also referred to as a "target name") but no
actions list; you either have the named permission or you
don't.

The target name is the name of a security configuration
parameter (see below). Currently the
SecurityPermission object is used to guard access to
the Policy, Security,
Provider, Signer, and
Identity objects.

The following table lists all the possible
SecurityPermission target names, and for each provides
a description of what the permission allows and a discussion of the
risks of granting code the permission.

java.security.SecurityPermission
Target Name

What the Permission Allows

Risks of Allowing this Permission

createAccessControlContext

Creation of an AccessControlContext

This allows someone to instantiate an
AccessControlContext with a
DomainCombiner. Extreme care must be taken when
granting this permission. Malicious code could create a
DomainCombiner that augments the set of permissions
granted to code, and even grant the code
AllPermission.

getDomainCombiner

Retrieval of an AccessControlContext's
DomainCombiner

This allows someone to query the policy via the getPermissions
call, which discloses which permissions would be granted to a given
CodeSource. While revealing the policy does not compromise the
security of the system, it does provide malicious code with
additional information which it may use to better aim an attack. It
is wise not to divulge more information than necessary.

getPolicy

Retrieval of the system-wide security policy (specifically, of
the currently-installed Policy object)

This allows someone to query the policy via the
getPermissions call, which discloses which permissions
would be granted to a given CodeSource. While
revealing the policy does not compromise the security of the
system, it does provide malicious code with additional information
which it may use to better aim an attack. It is wise not to divulge
more information than necessary.

setPolicy

Setting of the system-wide security policy (specifically, the
Policy object)

Granting this permission is extremely dangerous, as malicious
code may grant itself all the necessary permissions it needs to
successfully mount an attack on the system.

createPolicy.{policy type}

Getting an instance of a Policy via Policy.getInstance

Granting this permission enables code to obtain a Policy
object. Malicious code may query the Policy object to determine
what permissions have been granted to code other than itself.

getProperty.{key}

Retrieval of the security property with the specified key

Depending on the particular key for which access has been
granted, the code may have access to the list of security
providers, as well as the location of the system-wide and user
security policies. while revealing this information does not
compromise the security of the system, it does provide malicious
code with additional information which it may use to better aim an
attack.

setProperty.{key}

Setting of the security property with the specified key

This could include setting a security provider or defining the
location of the system-wide security policy. Malicious code that
has permission to set a new security provider may set a rogue
provider that steals confidential information such as cryptographic
private keys. In addition, malicious code with permission to set
the location of the system-wide security policy may point it to a
security policy that grants the attacker all the necessary
permissions it requires to successfully mount an attack on the
system.

insertProvider.{provider name}

Addition of a new provider, with the specified name

This would allow somebody to introduce a possibly malicious
provider (e.g., one that discloses the private keys passed to it)
as the highest-priority provider. This would be possible because
the Security object (which manages the installed providers)
currently does not check the integrity or authenticity of a
provider before attaching it.

removeProvider.{provider name}

Removal of the specified provider

This may change the behavior or disable execution of other
parts of the program. If a provider subsequently requested by the
program has been removed, execution may fail. Also, if the removed
provider is not explicitly requested by the rest of the program,
but it would normally be the provider chosen when a cryptography
service is requested (due to its previous order in the list of
providers), a different provider will be chosen instead, or no
suitable provider will be found, thereby resulting in program
failure.

clearProviderProperties.{provider name}

"Clearing" of a Provider so that it no longer contains the
properties used to look up services implemented by the
provider

This disables the lookup of services implemented by the
provider. This may thus change the behavior or disable execution of
other parts of the program that would normally utilize the
Provider, as described under the "removeProvider.{provider name}"
permission.

putProviderProperty.{provider name}

Setting of properties for the specified Provider

The provider properties each specify the name and location of a
particular service implemented by the provider. By granting this
permission, you let code replace the service specification with
another one, thereby specifying a different implementation.

removeProviderProperty.{provider name}

Removal of properties from the specified Provider

This disables the lookup of services implemented by the
provider. They are no longer accessible due to removal of the
properties specifying their names and locations. This may change
the behavior or disable execution of other parts of the program
that would normally utilize the Provider, as described under the
"removeProvider.{provider name}" permission.

The following permissions are associated with classes that have
been deprecated: Identity, IdentityScope,
Signer. Use of them is discouraged. See the applicable
classes for more information.

java.security.SecurityPermission
Target Name

What the Permission Allows

Risks of Allowing this Permission

setSystemScope

Setting of the system identity scope

This would allow an attacker to configure the system identity
scope with certificates that should not be trusted, thereby
granting applet or application code signed with those certificates
privileges that would have been denied by the system's original
identity scope.

setIdentityPublicKey

Setting of the public key for an Identity

If the identity is marked as "trusted", this allows an attacker
to introduce a different public key (e.g., its own) that is not
trusted by the system's identity scope, thereby granting applet or
application code signed with that public key privileges that would
have been denied otherwise.

setIdentityInfo

Setting of a general information string for an Identity

This allows attackers to set the general description for an
identity. This may trick applications into using a different
identity than intended or may prevent applications from finding a
particular identity.

addIdentityCertificate

Addition of a certificate for an Identity

This allows attackers to set a certificate for an identity's
public key. This is dangerous because it affects the trust
relationship across the system. This public key suddenly becomes
trusted to a wider audience than it otherwise would be.

removeIdentityCertificate

Removal of a certificate for an Identity

This allows attackers to remove a certificate for an identity's
public key. This is dangerous because it affects the trust
relationship across the system. This public key suddenly becomes
considered less trustworthy than it otherwise would be.

printIdentity

Viewing the name of a principal and optionally the scope in
which it is used, and whether or not it is considered "trusted" in
that scope.

The scope that is printed out may be a filename, in which case
it may convey local system information. For example, here's a
sample printout of an identity named "carol", who is marked not
trusted in the user's identity database:
carol[/home/luehe/identitydb.obj][not trusted]

getSignerPrivateKey

Retrieval of a Signer's private key

It is very dangerous to allow access to a private key; private
keys are supposed to be kept secret. Otherwise, code can use the
private key to sign various files and claim the signature came from
the Signer.

setSignerKeyPair

Setting of the key pair (public key and private key) for a
Signer

This would allow an attacker to replace somebody else's (the
"target's") keypair with a possibly weaker keypair (e.g., a keypair
of a smaller keysize). This also would allow the attacker to listen
in on encrypted communication between the target and its peers. The
target's peers might wrap an encryption session key under the
target's "new" public key, which would allow the attacker (who
possesses the corresponding private key) to unwrap the session key
and decipher the communication data encrypted under that session
key.

UnresolvedPermission

The java.security.UnresolvedPermission
class is used to hold Permissions that were
"unresolved" when the Policy was initialized. An
unresolved permission is one whose actual Permission
class does not yet exist at the time the Policy is
initialized (see below).

The policy for a Java runtime (specifying which permissions are
available for code from various principals) is represented by a
Policy object. Whenever a Policy is
initialized or refreshed, Permission objects of
appropriate classes are created for all permissions allowed by the
Policy.

Many permission class types referenced by the policy
configuration are ones that exist locally (i.e., ones that can be
found on CLASSPATH). Objects for such permissions can be
instantiated during Policy initialization. For
example, it is always possible to instantiate a
java.io.FilePermission, since the
FilePermission class is found on the CLASSPATH.

Other permission classes may not yet exist during
Policy initialization. For example, a referenced
permission class may be in a JAR file that will later be loaded.
For each such class, an UnresolvedPermission is
instantiated. Thus, an UnresolvedPermission is
essentially a "placeholder" containing information about the
permission.

Later, when code calls
AccessController.checkPermission on a permission of a
type that was previously unresolved, but whose class has since been
loaded, previously-unresolved permissions of that type are
"resolved". That is, for each such
UnresolvedPermission, a new object of the appropriate
class type is instantiated, based on the information in the
UnresolvedPermission. This new object replaces the
UnresolvedPermission, which is removed.

AWTPermission

The following table lists all the possible
AWTPermission target names, and for each provides a
description of what the permission allows and a discussion of the
risks of granting code the permission.

java.awt.AWTPermission
Target Name

What the Permission Allows

Risks of Allowing this Permission

accessClipboard

Posting and retrieval of information to and from the AWT
clipboard

This would allow malfeasant code to share potentially sensitive
or confidential information.

accessEventQueue

Access to the AWT event queue

After retrieving the AWT event queue, malicious code may peek
at and even remove existing events from the system, as well as post
bogus events which may purposefully cause the application or applet
to misbehave in an insecure manner.

accessSystemTray

Access to the AWT SystemTray instance

This would allow malicious code to add tray icons to the system
tray. First, such an icon may look like the icon of some known
application (such as a firewall or anti-virus) and order a user to
do something unsafe (with help of balloon messages). Second, the
system tray may be glutted with tray icons so that no one could add
a tray icon anymore.

createRobot

Create java.awt.Robot objects

The java.awt.Robot object allows code to generate
native-level mouse and keyboard events as well as read the screen.
It could allow malicious code to control the system, run other
programs, read the display, and deny mouse and keyboard access to
the user.

fullScreenExclusive

Enter full-screen exclusive mode

Entering full-screen exclusive mode allows direct access to
low-level graphics card memory. This could be used to spoof the
system, since the program is in direct control of rendering.

listenToAllAWTEvents

Listen to all AWT events, system-wide

After adding an AWT event listener, malicious code may scan all
AWT events dispatched in the system, allowing it to read all user
input (such as passwords). Each AWT event listener is called from
within the context of that event queue's
EventDispatchThread, so if the accessEventQueue
permission is also enabled, malicious code could modify the
contents of AWT event queues system-wide, causing the application
or applet to misbehave in an insecure manner.

readDisplayPixels

Readback of pixels from the display screen

Interfaces such as the java.awt.Composite
interface which allow arbitrary code to examine pixels on the
display enable malicious code to snoop on the activities of the
user.

replaceKeyboardFocusManager

Sets the KeyboardFocusManager for a particular
thread.

When a SecurityManager is installed, the invoking thread must
be granted this permission in order to replace the current
KeyboardFocusManager. If permission is not granted, a
SecurityException will be thrown.

setAppletStub

Setting the stub which implements Applet container
services

Malicious code could set an applet's stub and result in
unexpected behavior or denial of service to an applet.

The malicious window might make itself look and behave like a
real full desktop, so that information entered by the unsuspecting
user is captured and subsequently misused.

showWindowWithoutWarningBanner

Display of a window without also displaying a banner warning
that the window was created by an applet

Without this warning, an applet may pop up windows without the
user knowing that they belong to an applet. Since users may make
security-sensitive decisions based on whether or not the window
belongs to an applet (entering a username and password into a
dialog box, for example), disabling this warning banner may allow
applets to trick the user into entering such information.

When a toolkit-modal dialog is shown from an applet, it blocks
all other applets in the browser. When launching applications from
Java Web Start, its windows (such as the security dialog) may also
be blocked by toolkit-modal dialogs, shown from these
applications.

watchMousePointer

Getting the information about the mouse pointer position at any
time

Constantly watching the mouse pointer, an applet can make
guesses about what the user is doing, i.e. moving the mouse to the
lower left corner of the screen most likely means that the user is
about to launch an application. If a virtual keypad is used so that
keyboard is emulated using the mouse, an applet may guess what is
being typed.

FilePermission

A java.io.FilePermission
represents access to a file or directory. A
FilePermission consists of a pathname and a set of
actions valid for that pathname.

Pathname is 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 a directory and all the files contained in that
directory. A pathname that ends with "/-" indicates (recursively) all files and
subdirectories contained in that directory. A pathname consisting of the special token "<<ALL
FILES>>" matches any file.

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.

The actions to be granted are passed to the constructor in a
string containing a list of zero or more comma-separated keywords.
The possible keywords are "read", "write", "execute", and "delete".
Their meaning is defined as follows:

Keyword

Meaning

read

Permission to read.

write

Permission to write (which includes permission to
create).

execute

Permission to execute. Allows
Runtime.exec to be called. Corresponds to
SecurityManager.checkExec.

delete

Permission to delete. Allows
File.delete to be called. Corresponds to
SecurityManager.checkDelete.

The actions string is converted to lowercase before
processing.

Be careful when granting FilePermissions. Think
about the implications of granting read and especially write access
to various files and directories. The "<<ALL FILES>>"
permission with write action is especially dangerous. This grants
permission to write to the entire file system. One thing this
effectively allows is replacement of the system binary, including
the JVM runtime environment.

Note: Code can always read a file from the same directory it is in (or a subdirectory of that directory); it does not need explicit permission to do so. Code can also obtain the pathname of the directory it is executed from, and this pathname may contain sensitive information. For example, if code is executed from a home directory (or a subdirectory of the home directory), the pathname may reveal the name of the current user.

SerializablePermission

A java.io.SerializablePermission
is for serializable permissions. A
SerializablePermission contains a name (also referred
to as a "target name") but no actions list; you either have the
named permission or you don't.

The target name is the name of the Serializable permission (see
below).

The following table lists all the possible
SerializablePermission target names, and for each
provides a description of what the permission allows and a
discussion of the risks of granting code the permission.

java.io.SerializablePermission
Target Name

What the Permission Allows

Risks of Allowing this Permission

enableSubclassImplementation

Implementing a subclass of ObjectOutputStream or
ObjectInputStream to override the default
serialization or deserialization, respectively, of objects

Code can use this to serialize or deserialize classes in a
purposefully malfeasant manner. For example, during serialization,
malicious code can use this to purposefully store confidential
private field data in a way easily accessible to attackers. Or,
during deserializaiton it could, for example, deserialize a class
with all its private fields zeroed out.

enableSubstitution

Substitution of one object for another during serialization or
deserialization

This is dangerous because malicious code can replace the actual
object with one which has incorrect or malignant data.

ReflectPermission

A java.lang.reflect.ReflectPermission
is for reflective operations. A ReflectPermission is a named
permission and has no actions. The only name currently defined
is suppressAccessChecks, which allows suppressing the
standard language access checks -- for public, default (package)
access, protected, and private members -- performed by reflected
objects at their point of use.

The following table provides a summary description of what the
permission allows, and discusses the risks of granting code the
permission.

java.lang.reflect.ReflectPermission
Target Name

What the Permission Allows

Risks of Allowing this Permission

suppressAccessChecks

Warning:Extreme caution should be taken before
granting this permission to code, for it provides the ability
to access fields and invoke methods in a class. This includes not
only public, but protected and private fields and methods as
well.

This is dangerous in that information (possibly confidential)
and methods normally unavailable would be accessible to malicious
code.

RuntimePermission

A java.lang.RuntimePermission
is for runtime permissions. A RuntimePermission
contains a name (also referred to as a "target name") but no
actions list; you either have the named permission or you
don't.

The target name is the name of the runtime permission (see
below). 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.*" or
"*" is valid, "*loadLibrary" or
"a*b" is not valid.

The following table lists all the possible
RuntimePermission target names, and for each provides
a description of what the permission allows and a discussion of the
risks of granting code the permission.

java.lang.RuntimePermission Target Name

What the Permission Allows

Risks of Allowing this Permission

createClassLoader

Creation of a class loader

This is an extremely dangerous permission to grant. Malicious
applications that can instantiate their own class loaders could
then load their own rogue classes into the system. These newly
loaded classes could be placed into any protection domain by the
class loader, thereby automatically granting the classes the
permissions for that domain.

getClassLoader

Retrieval of a class loader (e.g., the class loader for the
calling class)

This would grant an attacker permission to get the class loader
for a particular class. This is dangerous because having access to
a class's class loader allows the attacker to load other classes
available to that class loader. The attacker would typically
otherwise not have access to those classes.

setContextClassLoader

Setting of the context class loader used by a thread

The context class loader is used by system code and extensions
when they need to lookup resources that might not exist in the
system class loader. Granting setContextClassLoader permission
would allow code to change which context class loader is used for a
particular thread, including system threads.

enableContextClassLoaderOverride

Subclass implementation of the thread context class loader
methods

The context class loader is used by system code and extensions
when they need to lookup resources that might not exist in the
system class loader. Granting enableContextClassLoaderOverride
permission would allow a subclass of Thread to override the methods
that are used to get or set the context class loader for a
particular thread.

setSecurityManager

Setting of the security manager (possibly replacing an existing
one)

The security manager is a class that allows applications to
implement a security policy. Granting the setSecurityManager
permission would allow code to change which security manager is
used by installing a different, possibly less restrictive security
manager, thereby bypassing checks that would have been enforced by
the original security manager.

createSecurityManager

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.

getenv.{variable name}

Reading of the value of the specified environment variable

This would allow code to read the value, or determine the
existence, of a particular environment variable. This is dangerous
if the variable contains confidential data.

exitVM.{exit status}

Halting of the Java Virtual Machine 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: The
"exitVM.*" permission is automatically granted to all code loaded
from the application class path, thus enabling applications to
terminate themselves. Also, the "exitVM" permission is equivalent
to "exitVM.*".

shutdownHooks

Registration and cancellation of virtual-machine shutdown
hooks

This allows an attacker to register a malicious shutdown hook
that interferes with the clean shutdown of the virtual
machine.

setFactory

Setting of the socket factory used by ServerSocket or Socket,
or of the stream handler factory used by URL

This allows code to set the actual implementation for the
socket, server socket, stream handler, or RMI socket factory. An
attacker may set a faulty implementation which mangles the data
stream.

setIO

Setting of System.out, System.in, and System.err

This allows changing the value of the standard system streams.
An attacker may change System.in to monitor and steal user input,
or may set System.err to a "null" OutputSteam, which would hide any
error messages sent to System.err.

This allows an attacker to modify the behavior of any thread in
the system.

stopThread

Stopping of threads via calls to the Thread stop
method

This allows code to stop any thread in the system provided that
it is already granted permission to access that thread. This poses
as a threat, because that code may corrupt the system by killing
existing threads.

This allows an attacker to create thread groups and set their
run priority.

getProtectionDomain

Retrieval of the ProtectionDomain for a class

This allows code to obtain policy information for a particular
code source. While obtaining policy information does not compromise
the security of the system, it does give attackers additional
information, such as local file names for example, to better aim an
attack.

getFileSystemAttributes

Retrieval of file system attributes

This allows code to obtain file system information such as disk
usage or disk space available to the caller. This is potentially
dangerous because it discloses information about the system
hardware configuration and some information about the caller's
privilege to write files.

readFileDescriptor

Reading of file descriptors

This would allow code to read the particular file associated
with the file descriptor read. This is dangerous if the file
contains confidential data.

writeFileDescriptor

Writing to file descriptors

This allows code to write to a particular file associated with
the descriptor. This is dangerous because it may allow malicous
code to plant viruses or at the very least, fill up your entire
disk.

loadLibrary.{library name}

Dynamic linking of the specified library

It is dangerous to allow an applet permission to load native
code libraries, because the Java security architecture is not
designed to and does not prevent malicious behavior at the level of
native code.

accessClassInPackage.
{package name}

Access to the specified package via a class loader's
loadClass method when that class loader calls the
SecurityManager checkPackageAcesss method

This gives code access to classes in packages to which it
normally does not have access. Malicious code may use these classes
to help in its attempt to compromise security in the system.

defineClassInPackage.
{package name}

Definition of classes in the specified package, via a class
loader's defineClass method when that class loader
calls the SecurityManager checkPackageDefinition
method.

This grants code permission to define a class in a particular
package. This is dangerous because malicious code with this
permission may define rogue classes in trusted packages like
java.security or java.lang, for
example.

accessDeclaredMembers

Warning: Extreme caution should be taken before
granting this permission to code, for it provides access to the
declared members of a class.

This grants code permission to query a class for its public,
protected, default (package) access, and private fields and/or
methods. Although the code would have access to the private and
protected field and method names, it would not have access to the
private/protected field data and would not be able to invoke any
private methods. Nevertheless, malicious code may use this
information to better aim an attack. Additionally, it may invoke
any public methods and/or access public fields in the class. This
could be dangerous if the code would normally not be able to invoke
those methods and/or access the fields because it can't cast the
object to the class/interface with those methods and fields.

queuePrintJob

Initiation of a print job request

This could print sensitive information to a printer, or simply
waste paper.

getStackTrace

Retrieval of the stack trace information of another
thread.

This allows retrieval of the stack trace information of another
thread. This might allow malicious code to monitor the execution of
threads and discover vulnerabilities in applications.

setDefaultUncaughtExceptionHandler

Setting the default handler to be used when a thread terminates
abruptly due to an uncaught exception.

This allows an attacker to register a malicious uncaught
exception handler that could interfere with termination of a
thread.

preferences

Represents the permission required to get access to the
java.util.prefs.Preferences implementations user or system root
which in turn allows retrieval or update operations within the
Preferences persistent backing store.

This permission allows the user to read from or write to the
preferences backing store if the user running the code has
sufficient OS privileges to read/write to that backing store. The
actual backing store may reside within a traditional filesystem
directory or within a registry depending on the platform OS.

NIO-Related Targets

Two NIO-related RuntimePermission targets were added
in the 1.4 release of the JavaSE JDK:

selectorProvider
charsetProvider

These RuntimePermissions are required to be granted to
classes which subclass and implement
java.nio.channel.spi.SelectorProvider or
java.nio.charset.spi.CharsetProvider. The permission
is checked during invocation of the abstract base class
constructor. These permissions ensure trust in classes which
implement these security-sensitive provider mechanisms.

NetPermission

A java.net.NetPermission
is for various network permissions. A NetPermission
contains a name but no actions list; you either have the named
permission or you don't.

The following table lists all the possible
NetPermission target names, and for each provides a
description of what the permission allows and a discussion of the
risks of granting code the permission.

java.net.NetPermission
Target Name

What the Permission Allows

Risks of Allowing this Permission

setDefaultAuthenticator

The ability to set the way authentication information is
retrieved when a proxy or HTTP server asks for authentication

Malicious code can set an authenticator that monitors and
steals user authentication input as it retrieves the input from the
user.

requestPasswordAuthentication

The ability to ask the authenticator registered with the system
for a password

Malicious code may steal this password.

specifyStreamHandler

The ability to specify a stream handler when constructing a
URL

Malicious code may create a URL with resources that it would
normally not have access to (like file:/foo/fum/), specifying a
stream handler that gets the actual bytes from someplace it does
have access to. Thus it might be able to trick the system into
creating a ProtectionDomain/CodeSource for a class even though that
class really didn't come from that location.

setProxySelector

The ability to set the proxy selector used to make decisions on
which proxies to use when making network connections.

Malicious code can set a ProxySelector that directs network
traffic to an arbitrary network host.

getProxySelector

The ability to get the proxy selector used to make decisions on
which proxies to use when making network connections.

Malicious code can get a ProxySelector to discover proxy hosts
and ports on internal networks, which could then become targets for
attack.

setCookieHandler

The ability to set the cookie handler that processes highly
security sensitive cookie information for an Http session.

Malicious code can set a cookie handler to obtain access to
highly security sensitive cookie information. Some web servers use
cookies to save user private information such as access control
information, or to track user browsing habit.

getCookieHandler

The ability to get the cookie handler that processes highly
security sensitive cookie information for an Http session.

Malicious code can get a cookie handler to obtain access to
highly security sensitive cookie information. Some web servers use
cookies to save user private information such as access control
information, or to track user browsing habit.

setResponseCache

The ability to set the response cache that provides access to a
local response cache.

Malicious code getting access to the local response cache could
access security sensitive information, or create false entries in
the response cache.

getResponseCache

The ability to get the response cache that provides access to a
local response cache.

SocketPermission

A java.net.SocketPermission
represents access to a network via sockets. A SocketPermission
consists of a host specification and a set of "actions" specifying
ways to connect to that host. The host is specified as

The host is expressed as a DNS name, as a numerical IP address,
or as "localhost" (for the local machine). The wildcard "*" may be
included once in a DNS name host specification. If it is included,
it must be in the leftmost position, as in "*.sun.com".

The port or portrange is optional. A port 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.

The possible ways to connect to the host are

accept
connect
listen
resolve

The "listen" action is only meaningful when used with
"localhost". The "resolve" (resolve host/ip name service lookups)
action is implied when any of the other actions are present.

As an example of the creation and meaning of SocketPermissions,
note that if you have the following entry in your policy file:

p2 represents a permission allowing accepting
connections on, connecting to, or listening on any port between
1024 and 65535 on the local host.

Note: Granting code permission to accept or make
connections to remote hosts may be dangerous because malevolent
code can then more easily transfer and share confidential data
among parties who may not otherwise have access to the data.

SQLPermission

The permission for which the SecurityManager will
check when code that is running in an applet, or an application
with an instance of SecurityManager enabled, calls one
of the following methods:

java.sql.DriverManager.setLogWriter

java.sql.DriverManager.setLogStream
(deprecated)

javax.sql.rowset.spi.SyncFactory.setJNDIContext

javax.sql.rowset.spi.SyncFactory.setLogger

java.sql.Connection.setNetworktimeout

java.sql.Connection.abort

If there is no SQLPermission object, these methods
throw a java.lang.SecurityException as a runtime
exception.

A SQLPermission object contains a name (also
referred to as a "target name") but no actions list; there is
either a named permission or there is not. The target name is the
name of the permission (see the following table that lists all the
possible SQLPermission names). The naming convention
follows the hierarchical property naming convention. In addition,
an asterisk (*) may appear at the end of the name,
following a dot (.), or by itself, to signify a
wildcard match. For example: loadLibrary.* or
* is valid, but *loadLibrary or
a*b is not valid.

The following table lists all the possible
SQLPermission target names. The table gives a
description of what the permission allows and a discussion of the
risks of granting code the permission.

Permission Target Name

What Permission Allows

Risks of Allowing This Permission

setLog

Setting of the logging stream

This is a dangerous permission to grant. The contents of the
log can contain usernames and passwords, SQL statements, and SQL
data.

callAbort

Invocation of the Connection method
abort

Permits an application to terminate a physical connection to a
database.

setSyncFactory

Invocation of the SyncFactory methods
setJNDIContext and setLogger

Permits an application to specify the JNDI context from which
the SyncProvider implementations can be retrieved from
and the logging object to be used by the SyncProvider
implementation.

setNetworkTimeout

Invocation of the Connection method
setNetworkTimeout

Permits an application to specify the maximum period a
Connection or objects created from the
Connection object will wait for the database to reply
to any one request.

The person running an applet decides what permissions to allow
and runs the Policy Tool to create an instance of
SQLPermission in a policy file. A programmer does not
use a constructor directly to create an instance of
SQLPermission but rather uses a tool.

PropertyPermission

The name is the name of the property ("java.home", "os.name",
etc). 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.*" or "*" is valid, "*java" or "a*b" is not
valid.

The actions to be granted are passed to the constructor in a
string containing a list of zero or more comma-separated keywords.
The possible keywords are "read" and "write". Their meaning is
defined as follows:

Keyword

Meaning

read

Permission to read. Allows
System.getProperty to be called.

write

Permission to write. Allows
System.setProperty to be called.

The actions string is converted to lowercase before
processing.

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 (the
location of the runtime environment's directory). Also, granting
permission to access the "user.name" and "user.home" system
properties gives potentially malevolent code sensitive information
about the user environment (the user's account name and home
directory).

LoggingPermission

A SecurityManager will check the java.util.logging.LoggingPermission
object when code running with a SecurityManager calls
one of the logging control methods (such as
Logger.setLevel).

Currently there is only one named
LoggingPermission, "control".
control 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.

Normally you do not create LoggingPermission
objects directly; instead they are created by the security policy
code based on reading the security policy file.

SSLPermission

The javax.net.ssl.SSLPermission
class is for various network permissions. An
SSLPermission contains a name (also referred to as a
"target name") but no actions list; you either have the named
permission or you don't.

The target name is the name of the network permission (see
below). 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: "foo.*" or
"*" is valid, "*foo" or
"a*b" is not valid.

The following table lists all the possible SSLPermission target
names, and for each provides a description of what the permission
allows and a discussion of the risks of granting code the
permission.

Permission Target Name

What the Permission Allows

Risks of Allowing this Permission

setHostnameVerifier

The ability to set a callback which can decide whether to allow
a mismatch between the host being connected to by an
HttpsURLConnection and the common name field in server
certificate.

Malicious code can set a verifier that monitors host names
visited by HttpsURLConnection requests or that allows
server certificates with invalid common names.

getSSLSessionContext

The ability to get the SSLSessionContext of an
SSLSession.

Malicious code may monitor sessions which have been established
with SSL peers or might invalidate sessions to slow down
performance.

AuthPermission

The javax.security.auth.AuthPermission
class is for authentication permissions. An
AuthPermission contains a name (also referred to as a
"target name") but no actions list; you either have the named
permission or you don't.

Currently the AuthPermission object is used to
guard access to the Subject,
SubjectDomainCombiner, LoginContext and
Configuration objects.

The following table lists all the possible
AuthPermission target names, and for each provides a
description of what the permission allows and a discussion of the
risks of granting code the permission.

Permission Target Name

What the Permission Allows

Risks of Allowing this Permission

doAs

Invocation of the Subject.doAs methods

This enables an application to invoke code (Actions) under the
identity of any Subject specified to the
doAs method.

doAsPrivileged

Invocation of the Subject.doAsPrivileged
methods

This enables an application to invoke code (Actions) under the
identity of any Subject specified to the
doAsPrivileged method. Additionally, the caller may
remove itself from the call stack (and hence from subsequent
security decisions) if it passes null as the
AccessControlContext.

getSubject

Retrieving the Subject from the provided
AccessControlContext

This permits an application to gain access to an authenticated
Subject. The application can then access the Subject's
authenticated Principals and public credentials.

getSubjectFromDomainCombiner

Retrieving the Subject from a
SubjectDomainCombiner

This permits an application to gain access to the authenticated
Subject associated with a
SubjectDomainCombiner. The application can then access
the Subject's authenticated Principals and public credentials.

setReadOnly

Setting a Subject read-only

This permits an application to set a Subject's
Principal, public credential and private credential
sets to be read-only. This can be potentially used as a type of
denial of service attack.

modifyPrincipals

Make modifications to a Subject's Principal
set

Access control decisions are based on the Principals associated
with a Subject. This permission permits an application
to make any modifications to a Subject's Principal
set, thereby affecting subsequent security decisions.

modifyPublicCredentials

Make modifications to a Subject's public credential set

This permission permits an application to add or remove public
credentials from a Subject. This may affect code that
relies on the proper set of private credentials to exist in that
Subject.

modifyPrivateCredentials

Make modifications to a Subject's private credential set

This permission permits an application to add or remove private
credentials from a Subject. This may affect code that
relies on the proper set of private credentials to exist in that
Subject.

refreshCredential

Refresh a credential Object that implements the
Refreshable interface

This permission permits an application to refresh a credential
that is intended to expire.

destroyCredential

Destroy a credential Object that implements the
Destroyable interface

This permission permits an application to potentially destroy a
credential as a denial of service attack.

createLoginContext.{name}

Instantiate a LoginContext with the specified
name

For security purposes, an administrator might not want an
application to be able to authenticate to any
LoginModule. This permission permits an application to
authenticate to the LoginModules configured for the specified
name.

getLoginConfiguration

Retrieve the system-wide login Configuration

Allows an application to determine all the LoginModules that
are configured for every application in the system.

setLoginConfiguration

Set the system-wide login Configuration

Allows an application to configure the LoginModules for every
application in the system.

createLoginConfiguration.{configuration type}

Obtain a Configuration object via
Configuration.getInstance

Allows an application to see all the LoginModules that are
specified in the configuration.

refreshLoginConfiguration

Refresh the system-wide login Configuration

Allows an application to refresh the login
Configuration.

PrivateCredentialPermission

The target name of this Permission specifies a
Credential class name, and a Set of Principals. The
only valid value for this Permission's actions is,
"read". The target name must abide by the following syntax:

CredentialClass {PrincipalClass "PrincipalName"}*

For example, the following permission grants access to the
com.sun.PrivateCredential owned by
Subjects which have a com.sun.Principal
with the name, "duke".

Note: Although this example, as well as all the examples
below, do not contain Codebase, SignedBy,
or Principal information in the grant statement (for
simplicity reasons), actual policy configurations should specify
that information when appropriate.

If CredentialClass is "*", then access is
granted to all private Credentials belonging to the
specified Subject. If "PrincipalName" is
"*", then access is granted to the specified
Credential owned by any Subject that has the
specified Principal (the actual PrincipalName
doesn't matter). For example, the following grants access to the
a.b.Credential owned by any Subject that has
an a.b.Principal.

The above code grants access to the private
Credential, "a.b.Credential", belonging
to a Subject with at least two associated
Principals: "a.b.Principal" with the
name, "duke", and "c.d.Principal", with
the name, "dukette".

DelegationPermission

The target name of this Permission specifies a pair of kerberos
service principals. The first is the subordinate service principal
being entrusted to use the Ticket Granting Ticket (TGT). The second
service principal designates the target service the subordinate
service principal is to interact with on behalf of the initiating
KerberosPrincipal. This latter service principal is
specified to restrict the use of a proxiable ticket.

For example, to specify the "host" service use of a forwardable
TGT, the target permission is specified as follows:

ServicePermission

The
javax.security.auth.kerberos.ServicePermission class is
used to protect Kerberos services and the credentials necessary to
access those services. There is a one to one mapping of a service
principal and the credentials necessary to access the service.
Therefore granting access to a service principal implicitly grants
access to the credential necessary to establish a security context
with the service principal. This applies regardless of whether the
credentials are in a cache or acquired via an exchange with the
KDC. The credential can be either a ticket granting ticket, a
service ticket or a secret key from a key table.

A ServicePermission contains a service principal
name and a list of actions which specify the context the credential
can be used within.

The service principal name is the canonical name of the
KereberosPrincipal supplying the service, that is the
KerberosPrincipal represents a Kerberos service
principal. This name is treated in a case sensitive manner.

Granting this permission implies that the caller can use a
cached credential (Ticket Granting Ticket, service ticket or secret
key) within the context designated by the action. In the case of
the TGT, granting this permission also implies that the TGT can be
obtained by an Authentication Service exchange.

The possible actions are:

Action

Meaning

initiate

Allows the caller to use the credential to initiate
a security context with a service principal.

accept

Allows the caller to use the credential to accept
security context as a particular principal.

For example, to specify the permission to access to the TGT to
initiate a security context the permission is constructed as
follows:

ServicePermission("krbtgt/EXAMPLE.COM@EXAMPLE.COM", "initiate");

To obtain a service ticket to initiate a context with the "host"
service the permission is constructed as follows:

ServicePermission("host/foo.example.com@EXAMPLE.COM", "initiate");

For a Kerberized server the action is "accept". For example, the
permission necessary to access and use the secret key of the
Kerberized "host" service (telnet and the likes) would be
constructed as follows:

ServicePermission("host/foo.example.com@EXAMPLE.COM", "accept");

AudioPermission

The javax.sound.sampled.AudioPermission
class represents access rights to the audio system resources. An
AudioPermission contains a target name but no actions
list; you either have the named permission or you don't.

The target name is the name of the audio permission (see the
table below). The names follow the hierarchical property-naming
convention. Also, an asterisk can be used to represent all the
audio permissions.

The following table lists the possible
AudioPermission target names. For each name, the table
provides a description of exactly what that permission allows, as
well as a discussion of the risks of granting code the
permission.

Permission Target Name

What the Permission Allows

Risks of Allowing this Permission

play

Audio playback through the audio device or devices on the
system. Allows the application to obtain and manipulate lines and
mixers for audio playback (rendering).

In some cases use of this permission may affect other
applications because the audio from one line may be mixed with
other audio being played on the system, or because manipulation of
a mixer affects the audio for all lines using that mixer.

record

Audio recording through the audio device or devices on the
system. Allows the application to obtain and manipulate lines and
mixers for audio recording (capture).

In some cases use of this permission may affect other
applications because manipulation of a mixer affects the audio for
all lines using that mixer. This permission can enable an applet or
application to eavesdrop on a user.

Methods and
the Permissions They Require

The following table contains a list of all the methods that
require permissions, and for each tells which
SecurityManager method it calls and which permission
is checked for by the default implementation of that
SecurityManager method.

Thus, with the default SecurityManager method
implementations, a call to a method in the left-hand column can
only be successful if the permission specified in the corresponding
entry in the right-hand column is allowed by the policy currently
in effect. For example, the following row:

Method

SecurityManager Method Called

Permission

java.awt.Toolkit
getSystemEventQueue();

checkAwtEventQueueAccess

java.awt.AWTPermission "accessEventQueue";

specifies that a call to the getSystemEventQueue
method in the java.awt.Toolkit class results in a call
to the checkAwtEventQueueAccess SecurityManager
method, which can only be successful if the following permission is
granted to code on the call stack:

java.awt.AWTPermission "accessEventQueue";

The convention of:

Method

SecurityManager Method Called

Permission

some.package.class
public static void someMethod(String foo);

checkXXX

SomePermission "{foo}";

means the runtime value of foo replaces the string
{foo} in the permission name.

As an example, here is one table entry:

Method

SecurityManager Method Called

Permission

java.io.FileInputStream
FileInputStream(String name)

checkRead(String)

java.io.FilePermission "{name}", "read";

If the FileInputStream method (in this case, a
constructor) is called with "/test/MyTestFile" as the
name argument, as in

FileInputStream("/test/MyTestFile");

then in order for the call to succeed, the following permission
must be set in the current policy, allowing read access to the file
"/test/MyTestFile":

java.io.FilePermission "/test/MyTestFile", "read";

More specifically, the permission must either be explicitly set,
as above, or implied by another permission, such as the
following:

java.io.FilePermission "/test/*", "read";

which allows read access to any files in the "/test"
directory.

In some cases, a term in braces is not exactly the same as the
name of a specific method argument but is meant to represent the
relevant value. Here is an example:

Here, the appropriate host and port values are calculated by the
receive method and passed to
checkAccept.

In most cases, just the name of the SecurityManager method
called is listed. Where the method is one of multiple methods of
the same name, the argument types are also listed, for example for
checkRead(String) and
checkRead(FileDescriptor). In other cases where
arguments may be relevant, they are also listed.

The following table is ordered by package name. That is, the
methods in classes in the java.awt package are listed
first, followed by methods in classes in the java.io
package, and so on.

Methods and the Permissions They
Require

Method

SecurityManager Method Called

Permission

java.awt.Graphics2d
public abstract void
setComposite(Composite comp)

checkPermission

java.awt.AWTPermission "readDisplayPixels" if this Graphics2D
context is drawing to a Component on the display screen and the
Composite is a custom object rather than an instance of the
AlphaComposite class. Note: The setComposite method is actually
abstract and thus can't invoke security checks. Each actual
implementation of the method should call the
java.lang.SecurityManager checkPermission method with a
java.awt.AWTPermission("readDisplayPixels") permission under the
conditions noted.

Note: The getPrintJob method is actually abstract and thus can't
invoke security checks. Each actual implementation of the method
should call the java.lang.SecurityManager checkPrintJobAccess
method, which is successful only if the java.lang.RuntimePermission
"queuePrintJob" permission is currently allowed.

java.awt.Toolkit
public abstract Clipboard
getSystemClipboard()

checkSystemClipboardAccess

java.awt.AWTPermission "accessClipboard"

Note: The getSystemClipboard method is actually abstract and
thus can't invoke security checks. Each actual implementation of
the method should call the java.lang.SecurityManager
checkSystemClipboardAccess method, which is successful only if the
java.awt.AWTPermission "accessClipboard" permission is currently
allowed.

java.awt.Toolkit
public final EventQueue
getSystemEventQueue()

checkAwtEventQueueAccess

java.awt.AWTPermission "accessEventQueue"

java.awt.Window
Window()

checkTopLevelWindow

If java.awt.AWTPermission "showWindowWithoutWarningBanner" is
set, the window will be displayed without a banner warning that the
window was created by an applet. It it's not set, such a banner
will be displayed.

If loader is null, and the caller's class loader
is not null, then
java.lang.RuntimePermission("getClassLoader")

java.lang.Class
public ClassLoader getClassLoader()

checkPermission

If the caller's class loader is null, or is the same as or an
ancestor of the class loader for the class whose class loader is
being requested, no permission is needed. Otherwise,
java.lang.RuntimePermission "getClassLoader"
is required.

java.lang.Class
public Class[] getDeclaredClasses()
public Field[] getDeclaredFields()
public Method[] getDeclaredMethods()
public Constructor[]
getDeclaredConstructors()
public Field getDeclaredField(
String name)
public Method getDeclaredMethod(...)
public Constructor
getDeclaredConstructor(...)

checkMemberAccess(this, Member.DECLARED) and, if this class is
in a package, checkPackageAccess({pkgName})

Default checkMemberAccess does not require any permissions if
"this" class's classloader is the same as that of the caller.
Otherwise, it requires java.lang.RuntimePermission
"accessDeclaredMembers". If this class is in a package,
java.lang.RuntimePermission "accessClassInPackage.{pkgName}" is
also required.

java.lang.Class
public Class[] getClasses()
public Field[] getFields()
public Method[] getMethods()
public Constructor[] getConstructors()
public Field getField(String name)
public Method getMethod(...)
public Constructor getConstructor(...)

checkMemberAccess(this, Member.PUBLIC) and, if class is in a
package, checkPackageAccess({pkgName})

Default checkMemberAccess does not require any permissions when
the access type is Member.PUBLIC. If this class is in a package,
java.lang.RuntimePermission "accessClassInPackage.{pkgName}" is
required.

If the caller's class loader is null, or is the same as or an
ancestor of the class loader for the class whose class loader is
being requested, no permission is needed. Otherwise,
java.lang.RuntimePermission "getClassLoader"
is required.

If the caller's class loader is null, or is the same as or an
ancestor of the context class loader for the thread whose context
class loader is being requested, no permission is needed.
Otherwise,
java.lang.RuntimePermission "getClassLoader"
is required.

java.lang.Thread
public void setContextClassLoader
(ClassLoader cl)

checkPermission

java.lang.RuntimePermission "setContextClassLoader"

java.lang.Thread
public final void checkAccess()
public void interrupt()
public final void suspend()
public final void resume()
public final void setPriority
(int newPriority)
public final void setName(String name)
public final void setDaemon(boolean on)

checkAccess(this)

java.lang.RuntimePermission "modifyThread"

java.lang.Thread
public static int
enumerate(Thread tarray[])

checkAccess({threadGroup})

java.lang.RuntimePermission "modifyThreadGroup"

java.lang.Thread
public final void stop()

checkAccess(this). Also checkPermission if the current thread
is trying to stop a thread other than itself.

java.lang.RuntimePermission "modifyThread".
Also java.lang.RuntimePermission "stopThread" if the current thread
is trying to stop a thread other than itself.

java.lang.Thread
public final synchronized void
stop(Throwable obj)

checkAccess(this). Also checkPermission if the current thread
is trying to stop a thread other than itself or obj is not an
instance of ThreadDeath.

java.lang.RuntimePermission "modifyThread".
Also java.lang.RuntimePermission "stopThread" if the current thread
is trying to stop a thread other than itself or obj is not an
instance of ThreadDeath.

java.lang.Thread
Thread(ThreadGroup group, ...)
java.lang.ThreadGroup
public final void checkAccess()
public int enumerate(Thread list[])
public int enumerate(Thread list[],
boolean recurse)
public int enumerate(ThreadGroup list[])
public int enumerate(ThreadGroup list[],
boolean recurse)
public final ThreadGroup getParent()
public final void
setDaemon(boolean daemon)
public final void setMaxPriority(int pri)
public final void suspend()
public final void resume()
public final void destroy()

checkAccess(this) for ThreadGroup methods, or
checkAccess(group) for Thread methods

java.lang.RuntimePermission "modifyThreadGroup"

java.lang.ThreadGroup
public final void interrupt()

checkAccess(this)

Requires java.lang.RuntimePermission "modifyThreadGroup".
Also requires java.lang.RuntimePermission "modifyThread", since the
java.lang.Thread interrupt() method is called for each thread in
the thread group and in all of its subgroups. See the Thread
interrupt() method.

java.lang.ThreadGroup
public final void stop()

checkAccess(this)

Requires java.lang.RuntimePermission "modifyThreadGroup".
Also requires java.lang.RuntimePermission "modifyThread" and
possibly java.lang.RuntimePermission "stopThread", since the
java.lang.Thread stop() method is called for each thread in the
thread group and in all of its subgroups. See the Thread stop()
method.

java.lang.SecurityManager Method Permission
Checks

This table shows which permissions are checked for by the
default implementations of the
java.lang.SecurityManager methods.

Each of the specified check methods calls the
SecurityManagercheckPermission method
with the specified permission, except for the
checkConnect and checkRead methods that
take a context argument. Those methods expect the context to be an
AccessControlContext and they call the context's
checkPermission method with the specified
permission.