* 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. *
* *
| Permission 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 {@link java.security.AllPermission}. |
*
| getDomainCombiner | *Retrieval of an AccessControlContext's DomainCombiner | *This allows someone to retrieve an AccessControlContext's
* DomainCombiner. Since DomainCombiners may contain
* sensitive information, this could potentially lead to a privacy leak. |
*
| 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 implementation from a provider | *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: {@link Identity}, {@link IdentityScope}, {@link Signer}. Use of * them is discouraged. See the applicable classes for more information. *
* *
| Permission 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. | *
name is null.
* @throws IllegalArgumentException if name is empty.
*/
public SecurityPermission(String name)
{
super(name);
}
/**
* Creates a new SecurityPermission object with the specified name.
* The name is the symbolic name of the SecurityPermission, and the
* actions String is currently unused and should be null.
*
* @param name the name of the SecurityPermission
* @param actions should be null.
*
* @throws NullPointerException if name is null.
* @throws IllegalArgumentException if name is empty.
*/
public SecurityPermission(String name, String actions)
{
super(name, actions);
}
}