Permission controls

The mms.cfg file is a text file that lets administrators enable or restrict access to a variety of capabilities. When Flash Player starts, it reads its security settings from this file, and uses them to limit functionality. The mms.cfg file includes settings that the administrator uses to manage capabilities such as privacy controls, local file security, socket connections, and so on.

A SWF file can access some information on capabilities that have been disabled by calling the Capabilities.avHardwareDisable and Capabilities.localFileReadDisable properties. However, most of the settings in the mms.cfg file cannot be queried from ActionScript.

To enforce application-independent security and privacy policies for a computer, the mms.cfg file should be modified only by system administrators. The mms.cfg file is not for use by application installers. While an installer running with administrative privileges could modify the contents of the mms.cfg file, Adobe considers such usage a violation of the user’s trust and urges creators of installers never to modify the mms.cfg file.

The mms.cfg file is stored in the following location:

• Windows 32-bit: system %WINDIR%\System32\Macromed\Flash\mms.cfg

  (for example, C:\WINDOWS\system32\Macromed\Flash\mms.cfg)

• Windows 64-bit: system %WINDIR%\SysWOW64\Macromed\Flash\mms.cfg

  (for example, C:\WINDOWS\sysWOW64\Macromed\Flash\mms.cfg)

• Mac: app support /Macromedia/mms.cfg

  (for example, /Library/Application Support/Macromedia/mms.cfg)

• Linux: /etc/adobe/mms.cfg

• Google Chrome: Google Chrome uses its own version of the mms.cfg file, saved at:

• Mac: /Users/(username) /Library/Application Support/Google/Chrome/Default/Pepper Data/Shockwave Flash/System

• Win: %USERNAME% /AppData/Local/Google/Chrome/User Data/Default/Pepper Data/Shockwave Flash/System

  The System directory may not exist. If not, create it manually.

  You might use third-party administration tools, such as Microsoft System Management Server, to replicate the configuration file to the user's computer.

  Use the standard techniques provided by your operating system to hide or otherwise prevent end users from seeing or modifying the mms.cfg file on their systems.

For more information about the mms.cfg file, see the Flash Player Administration Guide at www.adobe.com/go/flash_player_admin .

Administrative users and installer applications can register specified local SWF files as trusted for all users. These SWF files are assigned to the local-trusted sandbox. They can interact with any other SWF files, and they can load data from anywhere, remote or local. Files are designated as trusted in the Global Flash Player Trust directory, in the following location:

• Windows: system \Macromed\Flash\FlashPlayerTrust

  (for example, C:\WINDOWS\system32\Macromed\Flash\FlashPlayerTrust)

• Mac: app support /Macromedia/FlashPlayerTrust

  (for example, /Library/Application Support/Macromedia/FlashPlayerTrust)

The Flash Player Trust directory can contain any number of text files, each of which lists trusted paths, with one path per line. Each path can be an individual SWF file, HTML file, or directory. Comment lines begin with the # symbol. For example, a Flash Player trust configuration file containing the following text grants trusted status to all files in the specified directory and all subdirectories:

# Trust files in the following directories: 
C:\Documents and Settings\All Users\Documents\SampleApp

The paths listed in a trust configuration file should always be local paths or SMB network paths. Any HTTP path in a trust configuration file is ignored; only local files can be trusted.

To avoid conflicts, give each trust configuration file a filename corresponding to the installing application, and use a .cfg file extension.

As a developer distributing a locally run SWF file through an installer application, you can have the installer application add a configuration file to the Global Flash Player Trust directory, granting full privileges to the file that you are distributing. The installer application must be run by a user with administrative rights. Unlike the mms.cfg file, the Global Flash Player Trust directory is included for the purpose of installer applications granting trust permissions. Both administrative users and installer applications can designate trusted local applications using the Global Flash Player Trust directory.

There are also Flash Player Trust directories for individual users (see User controls ).

The Settings UI is a quick, interactive mechanism for configuring the settings for a specific domain. The Settings Manager presents a more detailed interface and provides the ability to make global changes that affect permissions for many or all domains. Additionally, when a new permission is requested by a SWF file, requiring run-time decisions concerning security or privacy, dialog boxes are displayed in which users can adjust some Flash Player settings.

The Settings Manager and Settings UI provide security-related options such as camera and microphone settings, shared object storage settings, settings related to legacy content, and so on. Neither the Settings Manager nor the Settings UI are available to AIR applications.

For details on the Settings Manager, see www.adobe.com/go/settingsmanager .

Users and installer applications can register specified local SWF files as trusted. These SWF files are assigned to the local-trusted sandbox. They can interact with any other SWF files, and they can load data from anywhere, remote or local. A user designates a file as trusted in the User Flash Player Trust directory, which is in same directory as the shared object storage area, in the following locations (locations are specific to the current user):

• Windows: app data\Macromedia\Flash Player\#Security\FlashPlayerTrust

  (for example, C:\Documents and Settings\JohnD\Application Data\Macromedia\Flash Player\#Security\FlashPlayerTrust on Windows XP or C:\Users\JohnD\AppData\Roaming\Macromedia\Flash Player\#Security\FlashPlayerTrust on Windows Vista)

  In Windows, the Application Data folder is hidden by default. To show hidden folders and files, select My Computer to open Windows Explorer, select Tools > Folder Options and then select the View tab. Under the View tab, select the Show hidden files and folders radio button.

• Mac: app data/Macromedia/Flash Player/#Security/FlashPlayerTrust

  (for example, /Users/JohnD/Library/Preferences/Macromedia/Flash Player/#Security/FlashPlayerTrust)

  These settings affect only the current user, not other users who log in to the computer. If a user without administrative rights installs an application in their own portion of the system, the User Flash Player Trust directory lets the installer register the application as trusted for that user.

  As a developer distributing a locally run SWF file by way of an installer application, you can have the installer application add a configuration file to the User Flash Player Trust directory, granting full privileges to the file that you are distributing. Even in this situation, the User Flash Player Trust directory file is considered a user control, because a user action (installation) initiates it.

  There is also a Global Flash Player Trust directory, used by the administrative user or installers to register an application for all users of a computer (see Administrator controls ).

By default, Flash Player (and AIR content that is not in the AIR application sandbox) first looks for a URL policy file named crossdomain.xml in the root directory of the server, and looks for a socket policy file on port 843. A file in either of these locations is called the master policy file . (In the case of socket connections, Flash Player also looks for a socket policy file on the same port as the main connection. However, a policy file found on that port is not considered a master policy file.)

In addition to specifying access permissions, the master policy file can also contain a meta-policy statement. A meta-policy specifies which locations can contain policy files. The default meta-policy for URL policy files is “master-only,” which means that /crossdomain.xml is the only policy file allowed on the server. The default meta-policy for socket policy files is “all,” which means that any socket on the host can serve a socket policy file.

A SWF file can check for a different policy filename or a different directory location by calling the Security.loadPolicyFile() method. However, if the master policy file doesn’t specify that the target location can serve policy files, the call to loadPolicyFile() has no effect, even if there is a policy file at that location. Call loadPolicyFile() before attempting any network operations that require the policy file. Flash Player automatically queues networking requests behind their corresponding policy file attempts. So, for example, it is acceptable to call Security.loadPolicyFile() immediately before initiating a networking operation.

When checking for a master policy file, Flash Player waits three seconds for a server response. If a response isn’t received, Flash Player assumes that no master policy file exists. However, there is no default timeout value for calls to loadPolicyFile() ; Flash Player assumes that the file being called exists, and waits as long as necessary to load it. Therefore, if you want to make sure that a master policy file is loaded, use loadPolicyFile() to call it explicitly.

Even though the method is named Security.loadPolicyFile() , a policy file isn’t loaded until a network call that requires a policy file is issued. Calls to loadPolicyFile() simply tell Flash Player where to look for policy files when they are needed.

You can’t receive notification of when a policy file request is initiated or completed, and there is no reason to do so. Flash Player performs policy checks asynchronously, and automatically waits to initiate connections until after the policy file checks have succeeded.

The following sections contain information that applies only to URL policy files. For more information on socket policy files, see Connecting to sockets .

A URL policy file applies only to the directory from which it is loaded and to its child directories. A policy file in the root directory applies to the whole server; a policy file loaded from an arbitrary subdirectory applies only to that directory and its subdirectories.

A policy file affects access only to the particular server on which it resides. For example, a policy file located at https://www.adobe.com:8080/crossdomain.xml applies only to data- loading calls made to www.adobe.com over HTTPS at port 8080.

The following example shows a URL policy file that permits access to SWF files that originate from *.example.com, www.friendOfExample.com and 192.0.34.166:

<?xml version="1.0"?> 
<cross-domain-policy> 
    <allow-access-from domain="*.example.com" /> 
    <allow-access-from domain="www.friendOfExample.com" /> 
    <allow-access-from domain="192.0.34.166" /> 
</cross-domain-policy>

If you specify an IP address, access is granted only to SWF files loaded from that IP address using IP syntax (for example, http://65.57.83.12/flashmovie.swf). Access isn’t granted to SWF files using domain-name syntax. Flash Player does not perform DNS resolution.

You can permit access to documents originating from any domain, as shown in the following example:

<?xml version="1.0"?> 
<!-- http://www.foo.com/crossdomain.xml --> 
<cross-domain-policy> 
<allow-access-from domain="*" /> 
</cross-domain-policy>

Each <allow-access-from> tag also has the optional secure attribute, which defaults to true . If your policy file is on an HTTPS server and you want to allow SWF files on a non-HTTPS server to load data from the HTTPS server, you can set the attribute to false .

Setting the secure attribute to false could compromise the security offered by HTTPS. In particular, setting this attribute to false opens secure content to snooping and spoofing attacks. Adobe strongly recommends that you not set the secure attribute to false .

If data to be loaded is on an HTTPS server, but the SWF file loading it is on an HTTP server, Adobe recommends that you move the loading SWF file to an HTTPS server. Doing so lets you keep all copies of your secure data under the protection of HTTPS. However, if you decide that you must keep the loading SWF file on an HTTP server, add the secure="false" attribute to the <allow-access-from> tag, as shown in the following code:

<allow-access-from domain="www.example.com" secure="false" /> 

<cross-domain-policy> 
    <allow-http-request-headers-from domain="*" headers="SOAPAction"/> 
</cross-domain-policy>

If the allow-http-request-headers-from statement is in the master policy file, it applies to all directories on the host. Otherwise, it applies only to the directory and subdirectories of the policy file that contains the statement.

Loading data from a server or connecting to a socket is an asynchronous operation. Flash Player simply waits for the policy file to finish downloading before it begins the main operation. However, extracting pixel data from images or extracting sample data from sounds is a synchronous operation. The policy file must load before you can extract data. When you load the media, specify that it check for a policy file:

• When using the Loader.load() method, set the checkPolicyFile property of the context parameter, which is a LoaderContext object.

• When embedding an image in a text field using the <img> tag, set the checkPolicyFile attribute of the <img> tag to "true" , as in the following:

  <img checkPolicyFile = "true" src = "example.jpg">

• When using the Sound.load() method, set the checkPolicyFile property of the context parameter, which is a SoundLoaderContext object.

• When using the NetStream class, set the checkPolicyFile property of the NetStream object.

When you set one of these parameters, Flash Player first checks for any policy files that it already has downloaded for that domain. Then it looks for the policy file in the default location on the server, checking both for <allow-access-from> statements and for the presence of a meta-policy. Finally, it considers any pending calls to the Security.loadPolicyFile() method to see if they are in scope.