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