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