Security policies add power to the Safe Base interpreter so that a tclet that runs under them is not blind to the outside world. The added power involves access to files, to Web resources, to an electronic mail system, to a Web browser, and to arbitrary TCP/IP connections. These powers have been divided into security features.

A feature is a Tcl script that runs in the plugin's master interpreter and customizes the slave that executes a tclet. Tclets cannot execute features directly – tclets cause them to be executed by requesting a security policy with the policy command as described below in Writing Tclets.

Several features are shipped with version 2.0 of the plugin. These are configured in different ways to create all of the shipped security policies. They can be configured in other ways for new policies. For example, if you want a policy that is something like the home policy but different, then give it a name, POLICY and make a copy of home.cfg named POLICY.cfg. Then edit POLICY.cfg to create the desired policy and plugin.cfg to enable POLICY for the desired tclets. Do not change any of the configuration files for the home, javascript, or trusted policies.

The inside and outside policies, however, are not fully configured as shipped. It is expected that you will edit their configuration files. This is discussed at the end of the section.

Security policies are configured by declaring which features they use and by configuring those features. Each policy begins with a features section with allow statements that enable the desired features. For example, the home policy begins with the following section.

section features
    allow url
    allow network
    allow persist unless {[string match {UNKNOWN *} [getattr originURL]]}

A feature is configured much like a policy but it is configured in a policy's configuration file. Whereas a tclet can run only one policy per execution, there is no limit on the way features may be combined in one security policy.

Here are the features shipped with version 2.0 of the plugin.

persist

The persist feature enables access to persistent storage.

urls

The urls feature enables the ability to download Web resources.

network

The network feature enables the ability to make TCP/IP connections, that is, more general connections than required to download Web pages.

stream

The stream feature enables the ability to send electronic mail, read and write streams of various mime types, and invoke JavaScript commands.

unsafe

The unsafe feature restores the full power of Tcl/Tk.

To use the persist feature, a security policy must have allow persist in its features section. To configure this policy, its configuration file must have a section introduced with section persist. Configuration consists of setting some parameters. Here, for example, is the way it is configured in javascript.cfg.

# Number of allowed open files
constant openFilesLimit 4
# Number of allowed files in the persist storage directory
constant storedFilesLimit 6
# Max size of each file (in bytes): here we give 128K per file.
constant fileSizeLimit [expr 128*1024]

The method for choosing the persistent storage directory is complicated. In the previous section under "Persistent Storage for Tclets", I described it as an injection from the set of pairs of URL paths and policy names without bothering to describe the exact nature of the injection. The directory for persistent storage is changed by altering the input to this injection: the tclet writer has a little flexibility in determining which URL path is used and the system administrator has complete flexibility in determining which policy name is used. This declaration,

constant storage NAME

Remark

Although not directly documented, this declaration,

constant storage COMPLETE_DIR_NAME

adds a new twist: all the persistent storage directories for this policy will now be subdirectories of COMPLETE_DIR_NAME. This is a way of moving your persistent storage away from the directory chosen by the TEMP or TMP environment variable. If you include the policy name in COMPLETE_DIR_NAME, you can still think of the storage directory for any given execution of a tclet as being determined by policy name and URL path as described in the previous section.

For example, if you add

section persist
   constant storage /usr/persist/home

to home.cfg, then a tclet from this url

http://www.MapFree.com/sbf/tcl/book/canvas.tcl

will be placed, by default, in a subdirectory of /usr/persist/home that is unique to the path /tcl/book/canvas.tcl. This means, of course, that the subdirectory depends on both the policy name and the pathname.

Although this may be tempting, it requires that you alter configuration files for standard policies, something that the on-line documentation advises against, and it relies on behavior that is essentially undocumented.

To use the url feature, a security policy must have allow url in its features section. To configure this policy, its configuration file must have a section introduced with section urls. Configuration consists of some enabling statements that define the URLs that a tclet can access. Here is an example.

section urls
  allow *

Remark

The enabling statements in a urls section of a policy's configuration file determine which URLs a tclet may access. Do not confuse them with the enabling statements in a new trusted... section of the plugin.cfg file. The latter determine which tclets are authorized to run under a security policy.

To use the network feature, a security policy must have allow network in its features section. To configure this policy, its configuration file must have a section introduced with section hosts ports. Configuration consists of enabling statements that define the hosts and ports that may be used for a TCP/IP connection. The home policy, for example, has this section:

# What addresses can be used in a socket command?

section hosts ports
  # Expected format (by the network feature):
  # allow <hostPattern> <portPattern>
  allow $originSocketHost >1024
  allow $originSocketHost 21

Remark

For a security policy that provides the power to do something you would not like, you should be very leery of providing access to ports on machines you do not control. For example, port 21 is reserved for the ftp program. But what is to say it is actually used that way on another organization's computer?

A script from a trusted source, written by an untrustworthy person could look benign, but because of its ability to access a port whose purpose is not what it ought to be, the script might be able to act in a malicious fashion.

The unsafe feature needs no additional configuration – it simply permits everything to be done. The stream feature can be reconfigured but a description of how to do so would take us far from the subject matter of this book into mime types and browser characteristics.

There is also a "browser policy" which is misnamed and is really a feature. This feature has been adopted from an earlier version of the plugin to give access to the browser. I do not discuss this feature because the discussion would take us far from the subject matter of this book and also because it would take us into something that seems unfinished and therefore likely to change.

Inside and Outside Policies

The point of these policies is to draw a line between tclets that deal with your organization's internal data and those that deal with the rest of the world. These policies need to be configured by a system administrator. The first step is to partition the world of Internet resources into those internal to your organization, those external to your organization, and those that are forbidden. Make your own decision as to why something should be forbidden. There is no a priori reason why this category should not contain resources that might otherwise be called internal or external.

Remember to think in terms of all Internet resources, not just Web resources. If there is too much to think about, then place resources you do not need in the forbidden category. You can reclassify them on a case by case basis later when you have time to think about them.

Once you have the world of Internet resources safely partitioned, you can start configuring the inside and outside policies and determining which tclets can run under them.

Remark

One problem that does not arise is transmission of internal data to the outside by means of a tclet running as an insider that leaves data in persistent storage for a tclet running as an outsider. Even if both tclets come from the same host, i.e even if some host contains both inside and outside resources, persistent storage cannot be used for transfer of internal data to the outside because a tclet having access to internal data will run under the inside policy and a tclet having access to the external world will run under the outside policy. Unless you have done something stupid with the storage parameter, the use of different policies will force the use of different directories for persistent storage.

You determine which Internet resources a policy can use by editing the url and network sections. Those in inside.cfg should be limited to internal resources and those in outside.cfg should be limited to external resources.

You determine which tclets can run under a policy by editing policy.cfg. Create a trustedInsideURLs section and authorize only tclets that come from internal resources. Create a trustedOutsideURLs section and authorize only tclets that come from external resources. Of course, you must also change the statements that disallow the inside and outside policies to appropriate allow statements as explained in the previous section.