Understanding Sandboxes
| Sandbox security takes its name from its real-world counterpart: Just as children are allowed to build anything they please within the confines of a sandbox, developers can be restricted to write and read code only within a virtual sandbox. In the case of ColdFusion Server, developers can be restricted to a set of directory structuresthe virtual sandbox. This way, two different companies that each have an application hosted on the same server will not be able to read or write to each other's directories. Sandbox security applies restrictions on the directories in which ColdFusion templates exist. Permissions of parent directories propagate to subdirectories (their children). Sandboxes defined for subdirectories override the sandbox settings on parent directories. This enables administrators of shared hosted environments to set up a root sandbox for each application and create personalized sandboxes on subdirectories within the parent sandboxes, without compromising the security of sandboxes for the other hosted sites. Examine the following directory structure:
In this hierarchy, the Actors and Female directories automatically inherit any sandbox restrictions defined for the ows directory. The Female directory would inherit any sandbox restrictions defined for the Actors directory, leaving the ows sandbox intact. Sandbox definitions restrict access to the following resources:
TIP Read and Execute access to the files and subdirectories of the cf_web_root/CFIDE/adminapi directory must be allowed in order to use the Administrator API when sandbox security is enabled. Understanding File and Directory PermissionsColdFusion MX uses the Java security model for its file and directory permissions. An asterisk (*) represents all the files in the parent directory and a list of subdirectories, but not the files in those subdirectories. A dash (-) indicates all the files in the parent directory, a list of subdirectories, and all the files in those subdirectories. Table 9.1 illustrates the inheritance patterns of files and directories.
Table 9.2 illustrates the effect of permissions on files and directories.
Setting read permissions on the pathname C:\CFusionMX7\wwwroot\ows\Actors\* produces the following results:
Changes in ColdFusion MXPrevious versions of ColdFusion (4.x through 5.0) leveraged the Netegrity SiteMinder API for sandbox security as a part of ColdFusion's Advanced Security framework. Though still a directory-based access control mechanism, sandboxes in this framework came in two flavors: operating system and ColdFusion. An operating system sandboxavailable only on Windows-based systemsprotected OS-level resources by assigning privileges to Windows domain members. ColdFusion sandboxes protected resources by assigning privileges through security contexts. A security context contained policies and rules that defined access control to resources: applications, data sources, tags and functions, user objects, and so on. Administrators then added users and/or groups from a user directory (LDAP, NT SAM, or ODBC) to the policies in order to govern access. To define a sandbox in ColdFusion 5, you entered a name and chose either Operating System or ColdFusion in the ColdFusion Administrator, as shown in Figure 9.1. In the sandbox definition, you input the absolute path of the directory you wanted to restrict. If you chose Operating System, you would also enter an NT Domain, user name, and password. If you chose ColdFusion, you would use the page shown in Figure 9.2 to select a configured security context, and enter a user name and password. Figure 9.1. Choose your ColdFusion 5.0 sandbox type: Operating System or ColdFusion. Figure 9.2. Configuring your ColdFusion sandbox in ColdFusion 5.0. ColdFusion MX simplifies the entire resource-security paradigm by eliminating the dependency of user directories and security contexts. This adds flexibility to the framework, making it independent of users and completely directory based. Tag restrictions and the unsecured tag directory are now a part of sandbox security, giving you more structured control over dangerous tags without inhibiting functionality within ColdFusion Administrator. Administrators can even limit the access of IP tags (such as <cfftp>, <cfhttp>, and <cfldap>) to specific server IPs and ports. Changes in ColdFusion MX 7ColdFusion MX 7 adds <cfdocument> and <cfreport> to the list of available tag restrictions. It also adds GetGatewayHelper() and SendGatewayMessage() functions to the list of available function restrictions. The most significant change to sandbox/resource security introduced in ColdFusion MX 7 is the ability to restrict access to the CreateObject function by type. Administrators are now able to restrict access to COM, Java, or Web services without disabling access to ColdFusion components via the CreateObject function. In ColdFusion MX, developers were able to access undocumented administrator functions with <cfobject> and CreateObject() calls; for example: <cfscript> factory = createObject('java','coldfusion.server.ServiceFactory') </cfscript> Macromedia recommended disabling <cfobject> and CreateObject() in shared or untrusted environments, and recommended granting access to shared Java objects via <cfinvoke> (see Macromedia Security Bulletin MPSB04-10 at http://www.macromedia.com/devnet/security/security_zone/mpsb04-10.html). Disabling <cfobject> and CreateObject meant you couldn't use them to integrate safely with COM or Web Services objects. ColdFusion MX 7 allows administrators to secure their servers against developers hacking at administrative functionality via Java objects, without limiting COM and Web Services integration. Macromedia also tightened this loophole by automatically restricting the corresponding object types in the <cfobject> tag when access to COM, Java, or Web Services objects is disabled via CreateObject(). ColdFusion Edition DifferencesThe Enterprise editions of ColdFusion Server allow administrators to create several sandboxes. The Standard edition allows only the root sandbox configuration shown in Figure 9.3. The Developer edition is a fully functional limited-IP edition, intended for local development, to help developers learn how to build applications with ColdFusion. Because it is fully functional, administrators can also configure additional sandboxes with the Developer edition. Figure 9.3. Only the root sandbox exists in the ColdFusion Standard edition. NOTE Macromedia ColdFusion Server is available for download as a fully functional 30-day Trial edition. At the end of 30 days, it becomes the limited-IP Developer edition. Security DefaultsResource security is disabled by default in ColdFusion and must be enabled via the ColdFusion Administrator, shown in Figure 9.4. Administrator password protection and RDS password protection are enabled by default and configured with the passwords you used during the installation process. Figure 9.4. Sandbox security is disabled by default in ColdFusion Administrator. |
EAN: 2147483647
Pages: 240