Security policies make unsafe features available in a safe mediated manner in an untrusted interpreter. All access to unsafe features is mediated in the untrusted interpreter through aliases which transfer control to a master interpreter. The master interpreter can decide whether to allow or deny the access, modify the arguments and modify the returned result. An example policy is home, described in the home manual page.
You should read the section on the POLICY command to learn how to invoke the command. If you are interesting in how the internals of the policy command work, read the section on IMPLEMENTATION OF POLICY COMMAND. If you want to implement a new security policy, you should read the section on the IMPLEMENTATION OF SECURITY POLICIES. If you are a system administrator and want to learn how to install policies and how to enable or disable use of specific policies, read the sections on TRUST MAPPING, POLICY ADMINISTRATION and FILES. The SECURITY section discusses the general security considerations that affect your decision to enable or disable a policy. You should read the config manual page to understand configuration management and the syntax and structure of configuration files.
If invoked with no arguments, the policy command returns the name of a policy installed in the invoking interpreter, if one was installed. If no policy is currently installed, an empty string is returned. Only one policy may be installed in an interpreter, and it cannot be uninstalled later. For example, if a policy named home was installed in the invoking interpreter, the policy command when invoked with no arguments will return the string home:
policy => home
If the policy command is invoked with one or more arguments, the first argument is used as the name of a policy to install, and the rest of the arguments are passed to the policy initialization procedure (see below). The command will attempt to install that policy into the invoking interpreter. For example, to install the getMyMail policy with several arguments, the policy command could be invoked as follows:
policy getMyMail -name jones -color green => getMyMail
If the command succeeds, the policy has been installed in the invoking interpreter. The command may also cause an error that can be caught with catch; the invoking interpreter can then try to load a different policy.
The policy command can be invoked multiple times with exactly the same arguments; in that case, after the first invocation, it just returns the name of the installed policy and doesn't do anything else. This allows a Tclet to defer obtaining the policy until it is needed and then request it without having to check whether it was already obtained.
The policy command appears as an atomic action to the invoking interpreter. It either succeeds, and then the policy is installed, or it fails, in which case no side effects are visible in the invoking interpreter.
Other sections may also be present if the policy exercises control over access to named resources. For example, the configuration file for the outside policy, outside.cfg, lists the urls and hosts ports section to control which URLs can be fetched and which ports can be accessed via the socket command on what hosts.
You should exercise care when editing policy configuration files. Complicated combinations of allow and disallow statements should be avoided; they can easily lead to making resources available to a Tclet in an unintended manner, potentially opening up security holes.
First, if another policy was already installed in the invoking Tclet, the command returns an error immediately. Next, it verifies that the policy is allowed for this Tclet, as explained in the section on TRUST MAPPING below. If this check produces an error, it is propagated to the invoking Tclet.
If the security checks succeed, the master interpreter attempts to install each of the features that is allowed by the requested policy into the Tclet by invoking the feature installation procedure. Features are described in the feature manual page. If an error occurs at this stage, the interpreter containing the Tclet is killed to prevent it from executed in an undefined state that may result from partially installed features. If no error occurs, the policy is now loaded into the invoking interpreter.
During installation of a policy the master interpreter checks whether the invoking interpreter can use the requested policy. The master interpreter examines the allow and disallow statements in the policies section of plugin.cfg. If the policy is disallowed the requesting Tclet can not use that policy and the policy command will return an error. If the policy is not mentioned in this section, no Tclet can use the policy.
To install a new policy and enable it, you should edit the plugin.cfg file and add an allow statement that enables the policy in exactly the intended circumstances. To disable a policy completely, ensure that there are no allow statements in this section for the policy. If you want to disallow the policy under some condition (e.g. when the Tclet is loaded from a certain host), add a disallow statement that explicitly tests for that condition.
The risks incurred by policies stem from the combination of features each policy enables. These risks are listed in the manual entries for each feature, and the manual entry for each policy lists what features it enables; this allows you to quickly oversee the risks incurred by a specific policy.
The security risks can be divided into four general classes:
The policies provided with the Tcl plugin make a variety of resources available to Tclets. The policies have been carefully designed and documented to minimze the risks associated with their use. However, some policies are disabled by default because they provide access to features that would be dangerous in the hands of potentially malicious Tclets.
The 2.0 release of the Tcl plugin provides no mechanism for authenticating the author of a Tclet or web page, and thus has no way to associate a higher level of trust with a Tclet. In controlled situations such as when the plugin is used to view Tclets loaded from servers on a company's Intranet, it may be sufficient to trust the URL from which a Tclet is loaded. However, this is a very weak form of authentication and can be subverted when used for authenticating Tclets loaded from sites not under your control.
All of the above means that you carefully control, through settings in the application's master configuration, which Tclets can use each policy. Incorrect configuration exposes your computer and potentially other computers on the same network to the risks discussed above.
The use of policies in an application is controlled by settings in the policies section in the master configuration for that application. For the Tcl plugin, the master configuration is contained in the plugin.cfg file in the cfg::configDir directory.