1 /*
2 * Copyright (c) 1997, 2015, Oracle and/or its affiliates. All rights reserved.
3 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
4 *
5 * This code is free software; you can redistribute it and/or modify it
6 * under the terms of the GNU General Public License version 2 only, as
7 * published by the Free Software Foundation. Oracle designates this
8 * particular file as subject to the "Classpath" exception as provided
9 * by Oracle in the LICENSE file that accompanied this code.
10 *
11 * This code is distributed in the hope that it will be useful, but WITHOUT
12 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
13 * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
14 * version 2 for more details (a copy is included in the LICENSE file that
15 * accompanied this code).
16 *
17 * You should have received a copy of the GNU General Public License version
18 * 2 along with this work; if not, write to the Free Software Foundation,
19 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
20 *
21 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
22 * or visit www.oracle.com if you need additional information or have any
23 * questions.
24 */
25
26 package java.security;
27
28 import java.security.*;
29 import java.util.Enumeration;
30 import java.util.Hashtable;
31 import java.util.StringTokenizer;
32
33 /**
34 * This class is for security permissions. A {@code SecurityPermission}
35 * contains a name (also referred to as a "target name") but no actions list;
36 * you either have the named permission or you don't.
37 * <p>
38 * The target name is the name of a security configuration parameter
39 * (see below). Currently the {@code SecurityPermission} object is used to
40 * guard access to the {@link AccessControlContext}, {@link Policy},
41 * {@link Provider}, {@link Security}, {@link Signer}, and {@link Identity}
42 * objects.
43 * <p>
44 * The following table lists the standard {@code SecurityPermission}
45 * target names, and for each provides a description of what the permission
46 * allows and a discussion of the risks of granting code the permission.
47 *
48 * <table border=1 cellpadding=5 summary="target name,what the permission allows, and associated risks">
49 * <tr>
50 * <th>Permission Target Name</th>
51 * <th>What the Permission Allows</th>
52 * <th>Risks of Allowing this Permission</th>
53 * </tr>
54 *
55 * <tr>
56 * <td>authProvider.{provider name}</td>
57 * <td>Allow the named provider to be an AuthProvider for login and
58 * logout operations. </td>
59 * <td>This allows the named provider to perform login and logout
60 * operations. The named provider must extend {@code AuthProvider}
61 * and care must be taken to grant to a trusted provider since
62 * login operations involve sensitive authentication information
63 * such as PINs and passwords. </td>
64 * </tr>
65 *
66 * <tr>
67 * <td>createAccessControlContext</td>
68 * <td>Creation of an AccessControlContext</td>
69 * <td>This allows someone to instantiate an AccessControlContext
70 * with a {@code DomainCombiner}. Extreme care must be taken when
71 * granting this permission. Malicious code could create a DomainCombiner
72 * that augments the set of permissions granted to code, and even grant the
73 * code {@link java.security.AllPermission}.</td>
74 * </tr>
75 *
76 * <tr>
77 * <td>getDomainCombiner</td>
78 * <td>Retrieval of an AccessControlContext's DomainCombiner</td>
79 * <td>This allows someone to retrieve an AccessControlContext's
80 * {@code DomainCombiner}. Since DomainCombiners may contain
81 * sensitive information, this could potentially lead to a privacy leak.</td>
82 * </tr>
83 *
84 * <tr>
85 * <td>getPolicy</td>
86 * <td>Retrieval of the system-wide security policy (specifically, of the
87 * currently-installed Policy object)</td>
88 * <td>This allows someone to query the policy via the
89 * {@code getPermissions} call,
90 * which discloses which permissions would be granted to a given CodeSource.
91 * While revealing the policy does not compromise the security of
92 * the system, it does provide malicious code with additional information
93 * which it may use to better aim an attack. It is wise
94 * not to divulge more information than necessary.</td>
95 * </tr>
96 *
97 * <tr>
98 * <td>setPolicy</td>
99 * <td>Setting of the system-wide security policy (specifically,
100 * the Policy object)</td>
101 * <td>Granting this permission is extremely dangerous, as malicious
102 * code may grant itself all the necessary permissions it needs
103 * to successfully mount an attack on the system.</td>
104 * </tr>
105 *
106 * <tr>
107 * <td>createPolicy.{policy type}</td>
108 * <td>Getting an instance of a Policy implementation from a provider</td>
109 * <td>Granting this permission enables code to obtain a Policy object.
110 * Malicious code may query the Policy object to determine what permissions
111 * have been granted to code other than itself. </td>
112 * </tr>
113 *
114 * <tr>
115 * <td>getProperty.{key}</td>
116 * <td>Retrieval of the security property with the specified key</td>
117 * <td>Depending on the particular key for which access has
118 * been granted, the code may have access to the list of security
119 * providers, as well as the location of the system-wide and user
120 * security policies. while revealing this information does not
121 * compromise the security of the system, it does provide malicious
122 * code with additional information which it may use to better aim
123 * an attack.
124 </td>
125 * </tr>
126 *
127 * <tr>
128 * <td>setProperty.{key}</td>
129 * <td>Setting of the security property with the specified key</td>
130 * <td>This could include setting a security provider or defining
131 * the location of the system-wide security policy. Malicious
132 * code that has permission to set a new security provider may
133 * set a rogue provider that steals confidential information such
134 * as cryptographic private keys. In addition, malicious code with
135 * permission to set the location of the system-wide security policy
136 * may point it to a security policy that grants the attacker
137 * all the necessary permissions it requires to successfully mount
138 * an attack on the system.
139 </td>
140 * </tr>
141 *
142 * <tr>
143 * <td>insertProvider</td>
144 * <td>Addition of a new provider</td>
145 * <td>This would allow somebody to introduce a possibly
146 * malicious provider (e.g., one that discloses the private keys passed
147 * to it) as the highest-priority provider. This would be possible
148 * because the Security object (which manages the installed providers)
149 * currently does not check the integrity or authenticity of a provider
150 * before attaching it. The "insertProvider" permission subsumes the
151 * "insertProvider.{provider name}" permission (see the section below for
152 * more information).
153 * </td>
154 * </tr>
155 *
156 * <tr>
157 * <td>removeProvider.{provider name}</td>
158 * <td>Removal of the specified provider</td>
159 * <td>This may change the behavior or disable execution of other
160 * parts of the program. If a provider subsequently requested by the
161 * program has been removed, execution may fail. Also, if the removed
162 * provider is not explicitly requested by the rest of the program, but
163 * it would normally be the provider chosen when a cryptography service
164 * is requested (due to its previous order in the list of providers),
165 * a different provider will be chosen instead, or no suitable provider
166 * will be found, thereby resulting in program failure.</td>
167 * </tr>
168 *
169 * <tr>
170 * <td>clearProviderProperties.{provider name}</td>
171 * <td>"Clearing" of a Provider so that it no longer contains the properties
172 * used to look up services implemented by the provider</td>
173 * <td>This disables the lookup of services implemented by the provider.
174 * This may thus change the behavior or disable execution of other
175 * parts of the program that would normally utilize the Provider, as
176 * described under the "removeProvider.{provider name}" permission.</td>
177 * </tr>
178 *
179 * <tr>
180 * <td>putProviderProperty.{provider name}</td>
181 * <td>Setting of properties for the specified Provider</td>
182 * <td>The provider properties each specify the name and location
183 * of a particular service implemented by the provider. By granting
184 * this permission, you let code replace the service specification
185 * with another one, thereby specifying a different implementation.</td>
186 * </tr>
187 *
188 * <tr>
189 * <td>removeProviderProperty.{provider name}</td>
190 * <td>Removal of properties from the specified Provider</td>
191 * <td>This disables the lookup of services implemented by the
192 * provider. They are no longer accessible due to removal of the properties
193 * specifying their names and locations. This
194 * may change the behavior or disable execution of other
195 * parts of the program that would normally utilize the Provider, as
196 * described under the "removeProvider.{provider name}" permission.</td>
197 * </tr>
198 *
199 * </table>
200 *
201 * <P>
202 * The following permissions have been superseded by newer permissions or are
203 * associated with classes that have been deprecated: {@link Identity},
204 * {@link IdentityScope}, {@link Signer}. Use of them is discouraged. See the
205 * applicable classes for more information.
206 *
207 * <table border=1 cellpadding=5 summary="target name,what the permission allows, and associated risks">
208 * <tr>
209 * <th>Permission Target Name</th>
210 * <th>What the Permission Allows</th>
211 * <th>Risks of Allowing this Permission</th>
212 * </tr>
213 *
214 * <tr>
215 * <td>insertProvider.{provider name}</td>
216 * <td>Addition of a new provider, with the specified name</td>
217 * <td>Use of this permission is discouraged from further use because it is
218 * possible to circumvent the name restrictions by overriding the
219 * {@link java.security.Provider#getName} method. Also, there is an equivalent
220 * level of risk associated with granting code permission to insert a provider
221 * with a specific name, or any name it chooses. Users should use the
222 * "insertProvider" permission instead.
223 * <p>This would allow somebody to introduce a possibly
224 * malicious provider (e.g., one that discloses the private keys passed
225 * to it) as the highest-priority provider. This would be possible
226 * because the Security object (which manages the installed providers)
227 * currently does not check the integrity or authenticity of a provider
228 * before attaching it.</td>
229 * </tr>
230 *
231 * <tr>
232 * <td>setSystemScope</td>
233 * <td>Setting of the system identity scope</td>
234 * <td>This would allow an attacker to configure the system identity scope with
235 * certificates that should not be trusted, thereby granting applet or
236 * application code signed with those certificates privileges that
237 * would have been denied by the system's original identity scope.</td>
238 * </tr>
239 *
240 * <tr>
241 * <td>setIdentityPublicKey</td>
242 * <td>Setting of the public key for an Identity</td>
243 * <td>If the identity is marked as "trusted", this allows an attacker to
244 * introduce a different public key (e.g., its own) that is not trusted
245 * by the system's identity scope, thereby granting applet or
246 * application code signed with that public key privileges that
247 * would have been denied otherwise.</td>
248 * </tr>
249 *
250 * <tr>
251 * <td>setIdentityInfo</td>
252 * <td>Setting of a general information string for an Identity</td>
253 * <td>This allows attackers to set the general description for
254 * an identity. This may trick applications into using a different
255 * identity than intended or may prevent applications from finding a
256 * particular identity.</td>
257 * </tr>
258 *
259 * <tr>
260 * <td>addIdentityCertificate</td>
261 * <td>Addition of a certificate for an Identity</td>
262 * <td>This allows attackers to set a certificate for
263 * an identity's public key. This is dangerous because it affects
264 * the trust relationship across the system. This public key suddenly
265 * becomes trusted to a wider audience than it otherwise would be.</td>
266 * </tr>
267 *
268 * <tr>
269 * <td>removeIdentityCertificate</td>
270 * <td>Removal of a certificate for an Identity</td>
271 * <td>This allows attackers to remove a certificate for
272 * an identity's public key. This is dangerous because it affects
273 * the trust relationship across the system. This public key suddenly
274 * becomes considered less trustworthy than it otherwise would be.</td>
275 * </tr>
276 *
277 * <tr>
278 * <td>printIdentity</td>
279 * <td>Viewing the name of a principal
280 * and optionally the scope in which it is used, and whether
281 * or not it is considered "trusted" in that scope</td>
282 * <td>The scope that is printed out may be a filename, in which case
283 * it may convey local system information. For example, here's a sample
284 * printout of an identity named "carol", who is
285 * marked not trusted in the user's identity database:<br>
286 * carol[/home/luehe/identitydb.obj][not trusted]</td>
287 *</tr>
288 *
289 * <tr>
290 * <td>getSignerPrivateKey</td>
291 * <td>Retrieval of a Signer's private key</td>
292 * <td>It is very dangerous to allow access to a private key; private
293 * keys are supposed to be kept secret. Otherwise, code can use the
294 * private key to sign various files and claim the signature came from
295 * the Signer.</td>
296 * </tr>
297 *
298 * <tr>
299 * <td>setSignerKeyPair</td>
300 * <td>Setting of the key pair (public key and private key) for a Signer</td>
301 * <td>This would allow an attacker to replace somebody else's (the "target's")
302 * keypair with a possibly weaker keypair (e.g., a keypair of a smaller
303 * keysize). This also would allow the attacker to listen in on encrypted
304 * communication between the target and its peers. The target's peers
305 * might wrap an encryption session key under the target's "new" public
306 * key, which would allow the attacker (who possesses the corresponding
307 * private key) to unwrap the session key and decipher the communication
308 * data encrypted under that session key.</td>
309 * </tr>
310 *
311 * </table>
312 *
313 * @implNote
314 * Implementations may define additional target names, but should use naming
315 * conventions such as reverse domain name notation to avoid name clashes.
316 *
317 * @see java.security.BasicPermission
318 * @see java.security.Permission
319 * @see java.security.Permissions
320 * @see java.security.PermissionCollection
321 * @see java.lang.SecurityManager
322 *
323 *
324 * @author Marianne Mueller
325 * @author Roland Schemers
326 */
327
328 public final class SecurityPermission extends BasicPermission {
329
330 private static final long serialVersionUID = 5236109936224050470L;
331
332 /**
333 * Creates a new SecurityPermission with the specified name.
334 * The name is the symbolic name of the SecurityPermission. An asterisk
335 * may appear at the end of the name, following a ".", or by itself, to
336 * signify a wildcard match.
337 *
338 * @param name the name of the SecurityPermission
339 *
340 * @throws NullPointerException if {@code name} is {@code null}.
341 * @throws IllegalArgumentException if {@code name} is empty.
342 */
343 public SecurityPermission(String name)
344 {
345 super(name);
346 }
347
348 /**
349 * Creates a new SecurityPermission object with the specified name.
350 * The name is the symbolic name of the SecurityPermission, and the
351 * actions String is currently unused and should be null.
352 *
353 * @param name the name of the SecurityPermission
354 * @param actions should be null.
355 *
356 * @throws NullPointerException if {@code name} is {@code null}.
357 * @throws IllegalArgumentException if {@code name} is empty.
358 */
359 public SecurityPermission(String name, String actions)
360 {
361 super(name, actions);
362 }
363 }