001: /*
002: * @(#)SecurityPermission.java 1.29 06/10/10
003: *
004: * Copyright 1990-2006 Sun Microsystems, Inc. All Rights Reserved.
005: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER
006: *
007: * This program is free software; you can redistribute it and/or
008: * modify it under the terms of the GNU General Public License version
009: * 2 only, as published by the Free Software Foundation.
010: *
011: * This program is distributed in the hope that it will be useful, but
012: * WITHOUT ANY WARRANTY; without even the implied warranty of
013: * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
014: * General Public License version 2 for more details (a copy is
015: * included at /legal/license.txt).
016: *
017: * You should have received a copy of the GNU General Public License
018: * version 2 along with this work; if not, write to the Free Software
019: * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
020: * 02110-1301 USA
021: *
022: * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa
023: * Clara, CA 95054 or visit www.sun.com if you need additional
024: * information or have any questions.
025: *
026: */
027:
028: package java.security;
029:
030: import java.security.*;
031: import java.util.Enumeration;
032: import java.util.Hashtable;
033: import java.util.StringTokenizer;
034:
035: /**
036: * This class is for security permissions.
037: * A SecurityPermission contains a name (also referred to as a "target name")
038: * but no actions list; you either have the named permission
039: * or you don't.
040: * <P>
041: * The target name is the name of a security configuration parameter (see below).
042: * Currently the SecurityPermission object is used to guard access
043: * to the Policy, Security, Provider, Signer, and Identity
044: * objects.
045: * NOTE: <B>java.security.Signer, java.security.Identity</B> are found in J2ME
046: * CDC profiles such as J2ME Foundation Profile.
047: * <P>
048: * The following table lists all the possible SecurityPermission target names,
049: * and for each provides a description of what the permission allows
050: * and a discussion of the risks of granting code the permission.
051: * <P>
052: *
053: * <table border=1 cellpadding=5 summary="target name,what the permission allows, and associated risks">
054: * <tr>
055: * <th>Permission Target Name</th>
056: * <th>What the Permission Allows</th>
057: * <th>Risks of Allowing this Permission</th>
058: * </tr>
059: *
060: * <tr>
061: * <td>createAccessControlContext</td>
062: * <td>Creation of an AccessControlContext</td>
063: * <td>This allows someone to instantiate an AccessControlContext
064: * with a <code>DomainCombiner</code>. Since DomainCombiners are given
065: * a reference to the ProtectionDomains currently on the stack,
066: * this could potentially lead to a privacy leak if the DomainCombiner
067: * is malicious.</td>
068: * </tr>
069: *
070: * <tr>
071: * <td>getDomainCombiner</td>
072: * <td>Retrieval of an AccessControlContext's DomainCombiner</td>
073: * <td>This allows someone to retrieve an AccessControlContext's
074: * <code>DomainCombiner</code>. Since DomainCombiners may contain
075: * sensitive information, this could potentially lead to a privacy leak.</td>
076: * </tr>
077: *
078: * <tr>
079: * <td>getPolicy</td>
080: * <td>Retrieval of the system-wide security policy (specifically, of the
081: * currently-installed Policy object)</td>
082: * <td>This allows someone to query the policy via the
083: * <code>getPermissions</code> call,
084: * which discloses which permissions would be granted to a given CodeSource.
085: * While revealing the policy does not compromise the security of
086: * the system, it does provide malicious code with additional information
087: * which it may use to better aim an attack. It is wise
088: * not to divulge more information than necessary.</td>
089: * </tr>
090: *
091: * <tr>
092: * <td>setPolicy</td>
093: * <td>Setting of the system-wide security policy (specifically,
094: * the Policy object)</td>
095: * <td>Granting this permission is extremely dangerous, as malicious
096: * code may grant itself all the necessary permissions it needs
097: * to successfully mount an attack on the system.</td>
098: * </tr>
099: *
100: * <tr>
101: * <td>getProperty.{key}</td>
102: * <td>Retrieval of the security property with the specified key</td>
103: * <td>Depending on the particular key for which access has
104: * been granted, the code may have access to the list of security
105: * providers, as well as the location of the system-wide and user
106: * security policies. while revealing this information does not
107: * compromise the security of the system, it does provide malicious
108: * code with additional information which it may use to better aim
109: * an attack.
110: </td>
111: * </tr>
112: *
113: * <tr>
114: * <td>setProperty.{key}</td>
115: * <td>Setting of the security property with the specified key</td>
116: * <td>This could include setting a security provider or defining
117: * the location of the the system-wide security policy. Malicious
118: * code that has permission to set a new security provider may
119: * set a rogue provider that steals confidential information such
120: * as cryptographic private keys. In addition, malicious code with
121: * permission to set the location of the system-wide security policy
122: * may point it to a security policy that grants the attacker
123: * all the necessary permissions it requires to successfully mount
124: * an attack on the system.
125: </td>
126: * </tr>
127: *
128: * <tr>
129: * <td>insertProvider.{provider name}</td>
130: * <td>Addition of a new provider, with the specified name</td>
131: * <td>This would allow somebody to introduce a possibly
132: * malicious provider (e.g., one that discloses the private keys passed
133: * to it) as the highest-priority provider. This would be possible
134: * because the Security object (which manages the installed providers)
135: * currently does not check the integrity or authenticity of a provider
136: * before attaching it.</td>
137: * </tr>
138: *
139: * <tr>
140: * <td>removeProvider.{provider name}</td>
141: * <td>Removal of the specified provider</td>
142: * <td>This may change the behavior or disable execution of other
143: * parts of the program. If a provider subsequently requested by the
144: * program has been removed, execution may fail. Also, if the removed
145: * provider is not explicitly requested by the rest of the program, but
146: * it would normally be the provider chosen when a cryptography service
147: * is requested (due to its previous order in the list of providers),
148: * a different provider will be chosen instead, or no suitable provider
149: * will be found, thereby resulting in program failure.</td>
150: * </tr>
151: *
152: * <tr>
153: * <td>setSystemScope</td>
154: * <td>Setting of the system identity scope</td>
155: * <td>This would allow an attacker to configure the system identity scope with
156: * certificates that should not be trusted, thereby granting applet or
157: * application code signed with those certificates privileges that
158: * would have been denied by the system's original identity scope</td>
159: * </tr>
160: *
161: * <tr>
162: * <td>setIdentityPublicKey</td>
163: * <td>Setting of the public key for an Identity
164: * NOTE: <B>java.security.Identity</B> is found in J2ME CDC profiles such as
165: * J2ME Foundation Profile. </td>
166: * <td>If the identity is marked as "trusted", this allows an attacker to
167: * introduce a different public key (e.g., its own) that is not trusted
168: * by the system's identity scope, thereby granting applet or
169: * application code signed with that public key privileges that
170: * would have been denied otherwise.</td>
171: * </tr>
172: *
173: * <tr>
174: * <td>setIdentityInfo</td>
175: * <td>Setting of a general information string for an Identity
176: * NOTE: <B>java.security.Identity</B> is found in J2ME CDC profiles such as
177: * J2ME Foundation Profile. </td>
178: * <td>This allows attackers to set the general description for
179: * an identity. This may trick applications into using a different
180: * identity than intended or may prevent applications from finding a
181: * particular identity.</td>
182: * </tr>
183: *
184: * <tr>
185: * <td>addIdentityCertificate</td>
186: * <td>Addition of a certificate for an Identity
187: * NOTE: <B>java.security.Identity</B> is found in J2ME CDC profiles such as
188: * J2ME Foundation Profile.</td>
189: * <td>This allows attackers to set a certificate for
190: * an identity's public key. This is dangerous because it affects
191: * the trust relationship across the system. This public key suddenly
192: * becomes trusted to a wider audience than it otherwise would be.</td>
193: * </tr>
194: *
195: * <tr>
196: * <td>removeIdentityCertificate</td>
197: * <td>Removal of a certificate for an Identity
198: * NOTE: <B>java.security.Identity</B> is found in J2ME CDC profiles such as
199: * J2ME Foundation Profile.</td>
200: * <td>This allows attackers to remove a certificate for
201: * an identity's public key. This is dangerous because it affects
202: * the trust relationship across the system. This public key suddenly
203: * becomes considered less trustworthy than it otherwise would be.</td>
204: * </tr>
205: *
206: * <tr>
207: * <td>printIdentity</td>
208: * <td>Viewing the name of a principal
209: * and optionally the scope in which it is used, and whether
210: * or not it is considered "trusted" in that scope</td>
211: * <td>The scope that is printed out may be a filename, in which case
212: * it may convey local system information. For example, here's a sample
213: * printout of an identity named "carol", who is
214: * marked not trusted in the user's identity database:<br>
215: * carol[/home/luehe/identitydb.obj][not trusted]</td>
216: *</tr>
217: *
218: * <tr>
219: * <td>clearProviderProperties.{provider name}</td>
220: * <td>"Clearing" of a Provider so that it no longer contains the properties
221: * used to look up services implemented by the provider</td>
222: * <td>This disables the lookup of services implemented by the provider.
223: * This may thus change the behavior or disable execution of other
224: * parts of the program that would normally utilize the Provider, as
225: * described under the "removeProvider.{provider name}" permission.</td>
226: * </tr>
227: *
228: * <tr>
229: * <td>putProviderProperty.{provider name}</td>
230: * <td>Setting of properties for the specified Provider</td>
231: * <td>The provider properties each specify the name and location
232: * of a particular service implemented by the provider. By granting
233: * this permission, you let code replace the service specification
234: * with another one, thereby specifying a different implementation.</td>
235: * </tr>
236: *
237: * <tr>
238: * <td>removeProviderProperty.{provider name}</td>
239: * <td>Removal of properties from the specified Provider</td>
240: * <td>This disables the lookup of services implemented by the
241: * provider. They are no longer accessible due to removal of the properties
242: * specifying their names and locations. This
243: * may change the behavior or disable execution of other
244: * parts of the program that would normally utilize the Provider, as
245: * described under the "removeProvider.{provider name}" permission.</td>
246: * </tr>
247: *
248: * <tr>
249: * <td>getSignerPrivateKey</td>
250: * <td>Retrieval of a Signer's private key</td>
251: * <td>It is very dangerous to allow access to a private key; private
252: * keys are supposed to be kept secret. Otherwise, code can use the
253: * private key to sign various files and claim the signature came from
254: * the Signer.
255: * NOTE: <B>java.security.Signer</B> is found in J2ME CDC profiles such as
256: * J2ME Foundation Profile.</td>
257: * </tr>
258: *
259: * <tr>
260: * <td>setSignerKeyPair</td>
261: * <td>Setting of the key pair (public key and private key) for a Signer</td>
262: * <td>This would allow an attacker to replace somebody else's (the "target's")
263: * keypair with a possibly weaker keypair (e.g., a keypair of a smaller
264: * keysize). This also would allow the attacker to listen in on encrypted
265: * communication between the target and its peers. The target's peers
266: * might wrap an encryption session key under the target's "new" public
267: * key, which would allow the attacker (who possesses the corresponding
268: * private key) to unwrap the session key and decipher the communication
269: * data encrypted under that session key.</td>
270: * </tr>
271: *
272: * </table>
273: *
274: * @see java.security.BasicPermission
275: * @see java.security.Permission
276: * @see java.security.Permissions
277: * @see java.security.PermissionCollection
278: * @see java.lang.SecurityManager
279: *
280: * @version 1.21 00/02/02
281: *
282: * @author Marianne Mueller
283: * @author Roland Schemers
284: */
285:
286: public final class SecurityPermission extends BasicPermission {
287:
288: /**
289: * Creates a new SecurityPermission with the specified name.
290: * The name is the symbolic name of the SecurityPermission. An asterisk
291: * may appear at the end of the name, following a ".", or by itself, to
292: * signify a wildcard match.
293: *
294: * @param name the name of the SecurityPermission
295: */
296:
297: public SecurityPermission(String name) {
298: super (name);
299: }
300:
301: /**
302: * Creates a new SecurityPermission object with the specified name.
303: * The name is the symbolic name of the SecurityPermission, and the
304: * actions String is currently unused and should be null.
305: *
306: * @param name the name of the SecurityPermission
307: * @param actions should be null.
308: */
309:
310: public SecurityPermission(String name, String actions) {
311: super(name, actions);
312: }
313: }
|