The Tcl/Tk plugin is commonly known in the Tcl community as the Netscape plugin but it runs with some other browsers as well. This chapter is based on version 2.0 which was recently released at the time of writing. Over the past couple of years, the plugin has undergone rapid development and change. Earlier versions (including the alpha release of version 2.0) are very different than what is described here. Look for the most recent version of the plugin from Sun or Scriptics.

The plugin provides a Tcl/Tk interpreter to execute tclets. After the plugin is installed, it will be loaded whenever your Web browser recognizes that it has downloaded a tclet. The easiest way to ensure such recognition is to give the extension .tcl to the tclet. Although most tclets expect to run in Tk, the .tcl extension is commonly used. As a tclet executes, Tk's root window appears as an entire Web page or as part of another Web page. When a tclet places a widget in the slave's root window, that widget appears in the browser. When the user backs out of this Web page or links to another Web page, the plugin terminates. Each time the user reviews the page, the plugin restarts.

A tclet's root window will fill a Web page when it is downloaded as a Web page, for example, if another Web page links to it with the <A> tag. A tclet's root window will be part of a Web page if an <EMBED> tag in the containing page refers to it. In this case, the root window will have the dimensions given with the WIDTH and HEIGHT attributes of the <EMBED> tag. (See above in A Brief HTML Introduction for a description of the <EMBED> tag.)

Remark

If your tclet's file does not have the appropriate extension, you need to use the <EMBED> tag and you need to add this attribute:

TYPE="application/x-tcl"

Figure 21.1a shows an example display which will result if you fetch a URL from this book's Web site with a Netscape browser. This example is similar to the one developed above in Chapter 19, "Canvases." As you drag the dots the line or polygon changes shape. The "Make Smooth" button is used to change the figure from a line or polygon to a similar Bezier curve which is "pulled" in the direction of the dots rather than going through the dots.

Figure 21.1a: Geometric forms from a tclet.

The plugin was designed to help you manage risks to your privacy or the integrity of your file system. It permits a tclet like the one that generated Figure 21.1a to run without noticeable constraint because such tclets do not open any files, create any TCP/IP channels, or take any other action that could either access your file system or communicate with another computer. Even so innocuous a form of communication as sending email is prohibited. One reason is that a tclet could use email in a way that damages the reputation of the person whose name appears as the sender.

The plugin was not designed to manage all risks. Risks that are not so well managed involve the possibility that a tclet may try to deny you the use of your computer by keeping the processor busy or by using up your disk space. The main denial of service threat which the plugin tries to control is overuse of your disk space. However, the plugin controls some other things as well. For example, it denies a tclet access to a Tk command that is capable of grabbing control over all mouse input.

The plugin is managed with a master script that runs in an almost normal interpreter. The few abnormalities in this master interpreter have to do with the fact that it runs in an environment initiated by your Web browser. The master script creates a new slave interpreter to execute each downloaded tclet. This slave interpreter is called a Safe Base interpreter and it is not at all normal – it is born without dangerous powers.

To make up for the Safe Base interpreter's limitations, the plugin master script gives it a policy command which a tclet can use to request an upgraded interpreter whose additional powers are consistent with some security policy. A tclet may be authorized for more than one security policy but it cannot run under more than one policy during one execution.

Security policies are described in configuration files. In the default installation you will find these files in a directory named config that is a sibling of the directory containing the executables. A policy's configuration file determines which command set will be available to the tclet in the upgraded interpreter.

Remark

The concept of "command" in a slave interpreter is a little different than has been used so far in this book. See below in Customizing Slave Interpreters.

Here is a list of the security policies whose configuration files are shipped with version 2.0.

home policy

Gives the tclet the power to fetch other files from the same computer and directory that supplied the tclet. Files from subdirectories can also be fetched. This policy is pretty safe and, as shipped, the plugin lets any tclet run under it.

inside policy

This is meant to give a tclet the power to make TCP/IP connections within your local network. The policy needs more configuration before it can be used. See below in Combining Features into Policies.

javascript policy

Gives the tclet the powers used by a Web browser. These powers include the abilities to access your file system, to connect to an arbitrary resource using sockets, to run a Java script, and to send email. Do not let untrusted tclets use this policy.

outside policy

This is meant to give a tclet the power to make TCP/IP connections outside your local network. The policy needs more configuration before it can be used. See below in Combining Features into Policies.

trusted policy

Lets the tclet run in an ordinary Tcl/Tk interpreter. Since this involves permitting the full power of Tcl/Tk, you should be very careful about which tclets you permit to run under this policy. As currently shipped, the plugin permits no tclets to use this policy.

These policies have three things in common:

1. the general organization of their configuration files,

2. the method by which a tclet is authorized to use them, and

3. the mechanism by which they can provide persistent storage for tclets.

This section continues with three subsections, one devoted to each of these commonalities.

The Form of a Configuration File

The configuration file for a policy named NAME is itself named NAME.cfg and it consists of

• Comments, that is, lines that begin with #

• Section headers, that is, lines that begin with section

• Enabling lines, that is, lines that begin with allow or disallow

• Parameter setting lines, that is, lines that begin with constant

The major function of most sections is to provide a method of declaring which resources may be used. Resources may be such things as security policies, URLs, host/port pairs, and so forth. This function of a section is supported by the enabling lines which belong to it.

Some examples of enabling lines are:

allow home

Used in plugin.cfg to enable the home security policy for all tclets.

allow $originHomeDirURL*

Used in home.cfg to enable access to URLs from the same source as the tclet.

allow javascript ifallowed trustedJavascriptURLs $originURL

Used in plugin.cfg to enable the javascript security policy for some tclets.

disallow trusted

Used in plugin.cfg to disable the trusted security policy.

allow * *

Used in javascript.cfg to enable TCP/IP connections to any host and port.

The use of ifallowed is described in the next subsection. This subsection finishes with a description of the section command which is always followed by some arguments. Arguments such as policies, hosts, and ports are in one sense just names for strings which will be tested for acceptability as the configuration file is processed. In another sense, they tell the plugin's master script which section is being described and so they are not arbitrary names.

For example, section policies declares a section used to describe which policies are acceptable and section hosts ports declares a section used to describe which hosts and ports are acceptable network connections.

When a section is being used to test whether some resource may be used, the test is merely one of whether a string naming the resource fits a pattern. For example, after section urls, the test will be whether a URL fits a pattern. Pattern matching is done glob style. If the string matches the pattern in one of the allow statements in a section but does not match the pattern in any disallow statement, then the resource may be used.

Remark

Notice that a result of this rule is that disallow * will override any allow statement in a section.

After a section statement with multiple arguments, each argument names a separate string which must be matched. For example after section hosts ports, enabling statements must present two patterns. The first will be used to match a host computer and the second will be used to match a port on that computer. Each pattern must match for an enabling statement to score a match.

All lines in a configuration file undergo Tcl-style substitutions. This is the basis for patterns such as $originURL* and $originHomeDirURL*. In these cases a variable made available by the plugin master script is substituted: originURL contains a canonical version of the URL used to fetch the current tclet and originHomeDirURL contains that part originURL up to its file name. A "canonical" version of a URL is a complete URL with occurences of ../ removed from it.

A description of the available variables can be found in the on-line documentation for "plugin."

Exercise 21.1a

Here is a way to see what the contents of $originURL and $originHomeDirURL are. It involves executing a tclet that provides you with a command and root window the way a Tk interpreter does when used interactively. Even if you do not know much Tcl/Tk, you can do this exercise. If you do know some Tcl/Tk, the tclets mentioned here will be even more useful to you.

Here are two tclets that provide you with command and root windows.

1. The tclet console.tcl in your plugin directory. This directory is a peer of config. (Another peer is tk8.0 which also has a file console.tcl. This one is not a tclet.)

2. The tclet safeTk.tcl from this book's home Web directory.

Load one of these tclets into your plugin-enabled browser. If you cannot find the root window, that is OK, you do not need it now. In the command window, execute

getattr VARIABLE_NAME 

to see the value of one of originURL, originHomeDirURL, or any other variable described in plugin.cfg.

Solution

Remarks

1. You need to use getattr instead of normal Tcl variable substitution because these variables are not freely available in the interpreter that runs the tclet. These belong to the master interpreter that processes the configuration files.

2. Before writing patterns for allow and disallow, you should look at some values of originURL with the method described in Exercise 21.1a. You will notice that the port number :80 is always part of the URL. You will probably notice that the domain name is always in lowercase letters. These are things you must keep in mind when writing patterns for your installation.

Exercise 21.1b

Which of the following URLs,

http://www.MapFree.com/sbf/tcl/book/canvas.tcl
http://sunscript.sun.com/plugin/v2/share.html

are accepted by the following section?

section urls
allow http://www.mapfree.com/*
allow http://sunscript.sun.com/*
disallow http://sunscript.sun.com/plugin/*

Solution

There is a way in which string matching does not follow the glob style. Numeric strings matched with a pattern such as >10 or <=90 must be numbers that satisfy the given inequality for a match to occur.

Exercise 21.1c

Which of the following string pairs,

sunscript.sun.com 3
mapfree.com 3
sunscript.sun.com 2001
mapfree.com 2001

are accepted by this section?

section hosts ports
allow * >0
disallow mapfree.com *
disallow * <1024

Solution

Currently, the verification that a tclet may operate under a particular security policy depends on the URL that was used to fetch the tclet. Authorizations are made in plugin.cfg in the enabling statement that allows a particular policy to be used. The following two statements appear in the policies section of plugin.cfg as shipped.

allow home
allow javascript ifallowed trustedJavascriptURLs $originURL

You know from the previous section that an enabling statement will have at least as many arguments as given to the governing section statement. Sometimes there can be more arguments than specified by the section statement. The most important way for this to happen is for the first additional argument to be ifallowed.

The enabling statements just shown appear in a policies section so one argument is expected for them. The use of ifallowed above declares that a match with the javascript pattern is not acceptable unless the string contained in originURL meets the criteria declared in the section named trustedJavascriptURLs. A section of this name is included in plugin.cfg for the sole purpose of defining the URLs of those tclets which may run under the javascript policy. It looks like this:

section trustedJavascriptURLs
  allow http://sunscript.sun.com:80/plugin/javascript/*

The default plugin.cfg has no additional section for the home policy because this policy is permitted for any tclet. If you wanted to change that you would define a new section that would accept tclets for the home policy. If the new section is declared with section trustedHomeURLs, you would change allow home to

allow home ifallowed trustedHomeURLs $originURL

The inside, outside, and trusted policies, by default, are not permitted for any tclets and so they also lack sections defining which URLs may be used to download tclets for them. To change that you would create those sections and change the appropriate disallow statement to a suitable allow statement. Do not enable the inside or outside policies without first reading below in Combining Features into Policies.

Exercise 21.1d

Edit plugin.cfg so that the trusted policy may be run by any tclet whose URL begins with file:... .

If this is inappropriate for your situation then change it back right away. In general, as you edit any of the configuration files, you should make a backup copy first so that it will be easy to revert to the original version.

Solution

Exercise 21.1e

Try to edit plugin.cfg so that the home policy accepts all tclets except those coming from the author's domain, Mapfree.com.

Discuss the difficulties you have with this exercise.

If this is inappropriate for your situation then change it back right away. In general, as you edit any of the configuration files, you should make a backup copy first so that it will be easy to revert to the original version.

Solution

Remark

Beyond the difficulties brought to light in Exercise 21.1e, the method of using the URL from which a tclet comes to authorize that tclet for a security policy has a major theoretical flaw. A malicious entity that has gained control of the network around you can do "domain name spoofing," that is, can make you think you are obtaining tclets from server A when you are, in fact, obtaining them from server B.

For most of us, this theoretical flaw is not too important. But if the integrity and privacy of your data is valuable enough, you have to take the military planner's view and assume that whatever is possible for the enemy to do will, in fact, be done.

All the security policies listed above allow tclets to save and recover a few, size-limited files. Under these policies, a tclet uses the usual file handling commands to work with files but, in reality, these file handling commands are different in that the open command does not permit piping and strips all directory information from file names to enforce the rule that the plugin and not the script determines which directory is used.

A tclet can only access files in one particular directory each time it executes. This directory is not chosen in a straightforward way. Luckily you do not need to know the exact method. What you need to know is that the directory name is chosen for a given policy name and URL path by an injection (that is, a one-to-one function). Here "policy name" means the name of the policy under which the tclet is running and "URL path" means the URL from which the tclet was fetched.

Knowing the storage directory is a one-to-one function of a policy name and a URL pathname tells you that a tclet is prevented from accessing another tclet's files or from accessing its own files if it stored those files while executing under a different security policy. This observation, however, is slightly wrong because the concept of "URL path" is more flexible than I have explained so far.

Using a technique described below in Writing Tclets, a tclet can change the URL path used for determining its storage directory! However, its freedom in making that change is greatly limited. In particular, a tclet can remove a suffix of the URL path – provided that suffix is not so long it includes the part of the URL which determines the server and port. For example, a tclet fetched with this URL,

http://www.mapfree.com:80/sbf/tcl/book/safeTk.tcl

http://www.mapfree.com:80/sbf/tcl/book

The shortest URL path that this tclet can use is

http://www.mapfree.com:80/

Of course, in either case, the other tclet that is sharing the persistent storage must similarly shorten its URL path if data sharing is to occur.

What this flexibility means is, when you set up your authorizations to use security policies, you must assume that tclets obtained from the same server and running under the same security policy will be able to share persistent data.

As a system administrator, you are concerned with where in your directory tree these persistent-file directories will actually appear. They appear as a subtree that is rooted in the directory declared in a TEMP or TMP environment variable. The root of this subtree is a directory named persist.

Remark

The next section describes a method available to system administrators to permit tclets running under different policies to share persistent storage. I do not recommend its use.