[back to "Staying alert with Execution Control Lists"]

Workstation access options
Choose from these options when setting up a workstation ECL:

Access option	Allows formulas and code to
Access to the file system	Attach, detach, read to, and write from workstation files
Access to current database	Read and modify the current database
Access to environment variables	Use the @SetEnvironment and @GetEnvironment variables and LotusScript methods to access the NOTES.INI file
Access to non-Notes databases	Use @DBLookup, @DBColumn, and @DBCommand to access databases when the first parameter for these @functions is a database driver of another application
Access to external code	Run LotusScript classes and DLLs that are unknown to Notes
Access to external programs	Access other applications, including activating any OLE object
Ability to send mail	Use functions such as @MailSend to send mail
Ability to read other databases	Read information in databases other than the current database
Ability to modify other databases	Modify information in databases other than the current database
Ability to export data	Print, copy to the clipboard, import, and export data
Access to Workstation Security ECL	Modify the ECL

Java applet options
Note: Although this article concentrates specifically on workstation security ECLs, descriptions of Java and JavaScript security ECL options are also provided here.

When a Java applet runs within Notes, certain security restrictions are imposed on that applet. This is sometimes referred to as the "Java security sandbox". This security model protects against malicious code by determining what operations an applet can perform and what system resources it can access. These restrictions can be customized on a per-signature basis by enabling the checkboxes as described below.

Access option	Allows the applet to
Access to file system	Read and write files on the local file system.
Access to Notes Java classes	Load and call the Domino back-end object classes.
Access to network addresses	Bind to and accept connections on a privileged port (a port outside the range 0 to 1024) and establish connections with other servers.
Printing	Submit print jobs.
Access to system properties	Read system properties such as color settings and environment variables.
Dialog and clipboard access	Access to the system Clipboard and also determines whether the "security banner" is displayed in top-level windows. The security banner is a visual indication (usually a message like "Java Applet Window") that this window was created by a Java applet. This is done to ensure that a user does not inadvertently enter security-sensitive information into a dialog masquerading as a password dialog, for example. Enabling this checkbox causes the security banner not to be displayed.
Process-level access	Create threads and threadgroups, fork and execute external processes, load and link external libraries, access non-public members of classes using Java core reflection, and access the AWT event queue.

JavaScript options
The JavaScript ECL options control security for JavaScript executing within the Notes client, either on a Notes form or on a Web page rendered by the Notes browser. These options do not control JavaScript executed by other browsers including the Microsoft Internet Explorer browser, even when embedded within the Notes client.
The read and write options (under the general categories "Allow Read Data Access From" and "Allow Write Data Access To," respectively) control whether JavaScript code can read or modify JavaScript properties of the Window object. The Window object is the top-level object in the JavaScript document object model. It has properties that apply to the entire window. Securing access to the Window object secures access to other objects on the page since the JavaScript program cannot access the objects lower in the object model without first traversing the Window object.

You can control the security for these read and write options independently for three different classes of Window objects:

Window object class	Description
Source window	Controls JavaScript access to the Window object on the same page as the JavaScript code. Typically this is a very low security threat. Selecting this option does not prevent JavaScript calls if the call is made directly to the object on the source window. Doing so circumvents the Window object; therefore this ECL option is not enforced. The default is to allow read and write access.
Other window from same host	Controls JavaScript access to the Window object on a different page from the JavaScript code, but from a page using the same host. For example, JavaScript code on a page on www.lotus.com can access the Window object on another page on www.lotus.com. This allows two pages to interact if they are within the same frameset. This is a slightly higher security threat. The default is to allow read and write access.
Other window from different host	This is similar to "Other window from same host," except it enables access to the Window object on a different page within a frameset that uses a different host. For example, JavaScript code on a page on www.lotus.com can access the Window object on a page on any other server. This is the highest security threat because of the possibility of someone designing a frameset containing a page performing malicious actions accessing data on another page in the same frameset that you "trust," where you might type a password or some other sensitive information. The default is to not allow read and write access.

There are two additional ECL options that control whether JavaScript executing in the Notes client is authorized to open a new Web page or Notes document.

The following options are available in the "Allow Open Access To" category:

Option	Description
URL on same host	Controls access for opening a page or Notes document on the same host as the JavaScript code. The default is to allow open access.
URL on different host	Controls access for opening a page or Notes document on a different host as the JavaScript code. The default is to not allow open access.