Local Security Diagrams

The following diagrams summarize the explanation of local security privileges described in previous sections.

Origins and Sandboxes

All SWFs are placed in a sandbox when they are loaded into the Flash Player. Figure 5 shows how SWFs are assigned to sandboxes based on their origin. SWFs from the network, for example from a.com and b.com, are always placed in a sandbox that corresponds to their origin domain.

Figure 5. Sandbox assignments based on SWF origin

SWFs from local origins (local filesystems or UNC network paths) are placed into one of three sandboxes. By default, a local SWF is placed in the local-with-filesystem sandbox. Local files that have declared that they wish to have network access are placed in the local-with-networking sandbox. Local files that are registered as trusted (via the Settings Manager or configuration files) are placed in the local-trusted sandbox. (In Flash Player 7 and earlier, all local files are placed in the local-trusted sandbox.)

Any two SWFs in the same sandbox may interact freely with each other. Later diagrams explain how SWFs may interact with SWFs from other sandboxes, and with filesystems and servers.

Default Privileges

In Figure 5, arrows represented SWF origin. In the following series of diagrams, arrows illustrate access instead. Dashed arrows represent data loading and outlined arrows represent cross-scripting. Figure 6 illustrates the privileges available to SWFs that fall into default sandboxes.

Figure 6. Default sandbox assignments and the privileges available within these sandboxes by default

By default, local SWFs are placed in the local-with-filesystem sandbox. From this sandbox, SWFs may read (using XML.load(), for example) from files on local filesystems or UNC network paths but they may not communicate with the Internet in any way.

The privileges for remote SWFs are no different from Flash Player 7, with the exception that remote SWFs may no longer load local content. Remote SWFs are always placed in a sandbox corresponding to their origin domain. From the a.com sandbox, a SWF may read (using XML.load(), for example) from the server at a.com and may send data (using XML.send(), for example) anywhere on the Internet.

Permissions for Remote SWFs

Figure 7 illustrates privileges for remote SWFs that are not available by default but may be granted using permissions.

Figure 7. Privileges for remote SWFs available by permission

A SWF from a.com may read (using XML.load, for example) from the server at b.com if b.com has a policy file that permits access from a.com, or from all domains. A SWF from a.com may cross-script a SWF from b.com (calling an ActionScript method in the b.com SWF, for example) if the b.com SWF calls System.security.allowDomain(“a.com”). These permissions are available in Flash Player 7 and have not changed in Flash Player 8.

By default, remote SWFs may not cross-script local SWFs. However, local-with-networking SWFs and local-trusted SWFs are allowed to grant permissions for cross-scripting by remote SWFs, using System.security.allowDomain(). Local-with-filesystem SWFs are not allowed to grant such permissions because this would make it possible for a local-with-filesystem SWF and a remote SWF to cooperate in reading data from a local filesystem and sending the data to a web server.

Privileges for Trusted Local SWFs

Figure 8 shows the unrestricted privileges given to local-trusted SWFs. Local-trusted SWFs may read from local files, interact with any server, and script any other SWF.

Figure 8. Privileges for local-trusted SWFs

Permissions for Local-With-Filesystem SWFs

Figure 9 illustrates privileges for local-with-filesystem SWFs that are not available by default, but may be granted using permissions. Local-trusted SWFs may grant permission, using System.security.allowDomain(“*”), to be scripted by local-with-filesystem SWFs.

Figure 9. Privileges for local-with-filesystem SWFs available by permission

Note that permissions can only be granted to local-with-filesystem SWFs by granting permissions to all domains. The all-domains requirement reflects the fact that allowing access by local-with-filesystem SWFs is equivalent to allowing access by anyone because Flash Player cannot determine the origin of a local SWF.

Permissions cannot be granted to local-with-filesystem SWFs by remote SWFs or local-with-networking SWFs because this would make it possible for a local-with-filesystem SWF and a remote or local-with-networking SWF to cooperate in reading data from a local filesystem and sending the data to a web server.

In the absence of permissions, local-with-filesystem SWFs are allowed only to load data from local filesystems (using XML.load(), for example).

Privileges for Local-With-Networking SWFs

Figure 10 shows the default privileges available to local SWFs that have declared themselves local-with-networking rather than local-with-filesystem. In the absence of permissions, local-with-networking SWFs are only allowed to communicate with other local-with-networking SWFs and send data to servers (using XML.send(), for example).

Figure 10. Privileges for local-with-networking SWFs available by default

Permissions for Local-With-Networking SWFs

Figure 11 illustrates privileges for local-with-networking SWFs that are not available by default, but may be granted using permissions.

Figure 11. Privileges for local-with-networking SWFs available by permission

A local-with-networking SWF is allowed to read (using XML.load(), for example) from the server at a.com if a.com has a policy file that permits access from all domains.

A local-with-networking SWF is allowed to cross-script a SWF from a.com (calling an ActionScript method in the a.com SWF, for example) if the a.com SWF calls System.security.allowDomain(“*”). Similarly, a local-with-networking SWF will be allowed to cross-script a local-trusted SWF if the local-trusted SWF calls allowDomain(“*”).

Note that permissions can only be granted to local-with-networking SWFs by granting permissions to all domains. The all-domains requirement reflects the fact that allowing access by local-with-networking SWFs is equivalent to allowing access by anyone because Flash Player cannot determine the origin of a local SWF.

No permissions can ever be established to allow local-with-networking SWFs to read from local files.

Summary of Data Flow

Figure 12 summarizes the data flows that are possible with a maximal set of permissions in place.

Figure 12. Data flow summary

By using permissions, local-with-networking SWFs can be made completely interoperable with remote SWFs and servers. Permissions also make it possible for local-trusted SWFs to communicate freely with network resources and vice versa.

Note, however, that even with this maximal set of permissions, data cannot flow from local filesystems to the Internet without going through a local-trusted SWF.