Exception sites java file

Managing the Java Exception Site List

If you have recently upgraded to the latest version of Java 7 or 8 you would have noticed the increased security settings. One of the main changes is that now Java will by default block any applications which aren’t certified or on the Exception Site List. Since many enterprises need Java for inhouse apps, this can become an issue. In this guide we will cover how to globally and centrally manage sites in the Java Exception Site List.

To complete this task we will require three files

deployment.properties
deployment.config
exception.sites

By default Java settings are managed on a per user basis using the deployment.properties file
located in C:\Users\\AppData\LocalLow\Sun\Java\Deployment
The Exception Site List is also managed on a per user basis and is stored in a text file named exception.sites located in C:\Users\\AppData\LocalLow\Sun\Java\Deployment\security\exception.sites

To override these with global settings we will need to create a deployment.config file with the two lines below and place it in C:\Windows\Sun\Java\Deployment

deployment.system.config=file\:C\:/Windows/Sun/Java/Deployment/deployment.properties deployment.system.config.mandatory=false

The first line configures where to look for the deployment.properties file and the second line configures if the settings are to be enforced or not. Setting it to false will allow users to override the settings if required. You can configure the deployment.properties file to be stored on a network location if desired.

Next you need to create the deployment.properties file with the lines below and store it in the location you specified in the deployment.config file above.

#deployment.properties deployment.webjava.enabled=true deployment.security.level=HIGH deployment.security.level.locked deployment.user.security.exception.sites=//fileserver/Folder/exception.sites

In this example we are setting the default Java Security Level to High and telling Java to look on the network location for the exception.sites file which will populate the Exception Site List.

The deployment.properties file can be configured further to customise Java. The page below from Oracle will show you additional properties you can configure in this file.

Finally we need to create the exception.sites list with all the sites we want added to the Exception Site List. Simply enter each site on a separate line.

Once you have configured all three files and placed them in the correct location you should see instantly that your Java settings have updated. You can verify this through the Java Control Panel.

Источник

29 Exception Site List

This topic describes the Exception Site List feature, which provides a way for users to run Rich Internet Applications (RIAs) that otherwise would be blocked by security checks. The criteria used to determine if RIAs are allowed to run are becoming stricter. In some cases it might be difficult to update legacy RIAs to meet the security requirements and prevent them from being blocked. This feature enables users to continue to run these RIAs.

The exception site list contains URLs for sites that host RIAs that users want to run. RIAs that are launched from sites in the exception site list are allowed to run with the appropriate security prompts, even in the following circumstances, which would normally cause the RIA to be blocked:

• RIA is not signed with a certificate from a trusted certificate authority
• RIA is hosted locally
• JAR file does not have the Permission manifest attribute
• RIA is signed with an expired certificate
• Certificate used to sign the RIA cannot be checked for revocation

The exception site list also allows JavaScript code to call Java code (LiveConnect) without prompting the user for permission when the JavaScript code and the Java code are located on a site in the list.

This topic contains the following sections:

29.1 Manage the Exception Site List

The exceptions granted by the Exception Site List feature apply to RIAs whose entry point is included in the list:

• For applets, the URL for the document base of the applet must be in the list.
• For Java Web Start applications, the URL for the main JNLP file must be in the list. If the URL for the main JNLP file cannot be determined, then the exceptions do not apply to the RIA.

If the RIA requires resources from another domain, that domain must also be included in the exception site list. Otherwise, the RIA is blocked when the additional resource is accessed.

The exception site list is managed in the Security tab of the Java Control Panel which is described in Section 20.4, «Security.» The list is shown in the tab. To add, edit, or remove items from the list, click Edit Site List and follow the directions in Add a URL, Edit a URL, and Remove a URL.

29.1.1 Add a URL

To add a URL to the exception site list, follow these steps:

1. Click Add in the Exception Site List window.
2. Type the URL into the empty field that is provided under Location.
3. Continue to click Add and enter URLs until your list is complete.
4. Click OK to save the URLs that you entered. If you click Cancel, the URLs are not saved.

The following rules apply to the format of the URL:

• A protocol is required. Supported protocols are FILE , HTTP , and HTTPS . HTTPS is recommended. If the protocol is not HTTPS , a warning is shown. Click Continue to add the URL, or click Cancel to discard the URL.
• A domain is required. Wildcards are not supported. If only a domain is provided, any RIA from that domain is allowed to run. A domain can have multiple entries, for example, https://www.example.com and http://www.example.com .
• A port number is required only if the default port is not used.
• A path is optional. Wildcards are not supported. If the path ends with a slash (/), for example, https://www.example.com/apps/ , RIAs in that directory and any subdirectory are allowed to run. If the path does not end with a slash, for example, http://www.example.com/test/applet.html , only that specific RIA is allowed to run.
• The format must be the same as the format used for the RIA URL or href attribute. For example, https://www.example.com/sample/app/sample1/../sample2 and https://www.example.com/sample//app/sample2 are not considered matches to https://www.example.com/sample/app/sample2 .

Add a site to the exception site list only if you trust the entire site. Even if a path is specified, adding a site that might contain other untrusted paths could present a security risk and is not recommended.

If an invalid URL is entered, an error icon is shown next to the item. If the URL is not corrected before OK is clicked, the invalid URL is not saved.

29.1.2 Edit a URL

To edit a URL in the exception site list, follow these steps:

1. Double-click the URL that you want to edit in the Exception Site List window.
2. Make changes to the URL. See Add a URL for information on the format of the URL.
3. Click OK to save the changes. If you click Cancel, the changes are not saved.

29.1.3 Remove a URL

To remove a URL from the exception site list, follow these steps:

1. Click the URL that you want to remove in the Exception Site List window.
2. To remove more than one URL, Ctrl-click the additional URLs.
3. Click Remove.
4. Click OK to save your change. If you click Cancel, the URLs are not removed from the list.

29.2 Manage Access to the Exception Site List

The location of the exception site list is set in the deployment.user.security.exception.sites property. The default location is /security/exception.sites . See Chapter 21, «Deployment Configuration File and Properties» for information on properties and property files.

Users can manage a list on their system, or use a list managed by a system administrator in a central location. If a system administrator does not want users to edit the exception site list, the deployment.user.security.exception.sites property can be set to a file for which users do not have write permission. If a user cannot write to the exception site list, the list is shown in the Java Control Panel, but the controls for editing are not available in the Exception Site List window.

To prevent users from using a different exception site list than the list set up by a system administrator, the deployment.user.security.exception.sites property can be locked. See Section 21.2, «Deployment Configuration Properties» for information on locking system properties.

Источник

Java u51–Understanding Exceptions.Sites

In u45, Java released a ruleset file which was meant to solve system administrator’s problems with whitelisting sites and preventing popups on unsigned sites. The problem with the ruleset was it required administrators to leave their comfort zone and step into the Java developer world by creating jar files and signing them. When I heard the new version of Java came with a new way to whitelist sites, I was pretty excited. I thought Oracle finally included a system administrator friendly way to manage Java… I was wrong.

At first glance, this Exception.Sites file might seem like it has everything admins need. What more do you need to do other than whitelisting sites? Well there are a number of problems you’ll encounter using this method and I’m going to detail them here at the end of the post. If you wish to go ahead and use this method to manage Java (it’s not a horrible way to manage Java, it just isn’t the best way) I will show how you can centrally manage it with SCCM.

Oracle has said the exception.sites file is meant to be for users to manage while the deployment.ruleset is for users to manage. By default, exception.sites lives in the users profile at this path: C:\Users\UserName\AppData\LocalLow\Sun\Java\Deployment\Security

and each user manages their own site list through the Java control panel:

Administrators can change the location of this file for all users through two files in this folder: C:WindowsSunJavaDeployment

The first file you will want here is a file named deployment.config. If you have a fresh install of Java, you will probably have to create the folder and this file if they don’t exist. This properties file tells Java there are computer settings that need to be set. Any settings you set in the properties file will overwrite the user settings. The content of this file is:

deployment.system.config=C\:\\Windows\\Sun\\Java\\Deployment\\deployment.properties deployment.system.config.mandatory=false

The second file you need is deployment.properties. This file lists all the properties the admin has set for the computer. By default, there are no settings set so the file will probably not exist. Create it and put this line in:

deployment.user.security.exception.sites=C\:\\Windows\\Sun\\Java\\Deployment\\exception.sites

This line of code tells Java to use the exception.sites file in C:WindowsSunJavaDeploymentexception.sites instead of the user one. Make sure this file is in a location your users have read access to or this will not work. Also, if you set this and a user has write access to the file, they will be able to change the site list for all users who log into the computer. Java will not use the exception.sites list in their profile anymore.

And that’s it! Now you can manage the exception.sites list.

Why shouldn’t admins use this method? Well here is a little list:

1. Oracle provides a better way to manage exceptions through the deploymentruleset
2. This method only lets you whitelist. You can not set security levels, block sites, or set which version should be used on which site
3. This method doesn’t accept wildcards.
4. Users will not be able to add their own exceptions, so all needed exceptions will have to be set by you (this may be a positive, depending on the environment)

If you don’t care about these points, then by all means use the Exception.Sites file to manage Java. As I said at the start, it isn’t a horrible way to manage Java, it just doesn’t have all the features of the deploymentruleset.

Updated: March 07, 2014

Источник