Web Sablime^® Security Guide

What This Guide Covers

• assess the safety of the Web Sablime application
• install Web Sablime in a way that minimizes the possibilities of misuse
• monitor the application for signs of attempted misuse
• advise Sablime users about security issues

Overview of Web Sablime

Sablime users log in to a Unix host and run Sablime commands, or they access Sablime data and commands remotely via Web Sablime. Web Sablime access requires a login on the Unix host and a Web Sablime password. Web Sablime executes commands on the Unix host, under the remote user's login. It does this by means of a utility called sabexec, which must be installed as setuid-root. Much of this guide focuses on sabexec.

Web Sablime requires a web server. How secure the Web Sablime application is depends largely on how securely the web server is configured, and, in particular, which user the server process runs as. This guide contains specific recommendations, and also describes the security implications of other (non-recommended) configurations.

Web Sablime also manipulates files on the user's client machine: uploading files to the Sablime host, retrieving files from the Unix host, and removing files when they are returned to the Unix host after editing. It does this by means of the Web Sablime Java toolkit and certificate, which are installed on the client when the user first invokes a command that requires them. The toolkit will not operate without the certificate, and the certificate cannot be installed without the user's permission.

Files and Utilities used by Web Sablime

Sablime databases

These contain the files under Sablime control, plus modification requests (MRs), and information about products, generics, saved configurations, etc. The purpose of the Web Sablime application is to enable remote users to view and manipulate this data.

Host Sablime commands (edput, etc.)

The commands used by local users (users logged in to the Unix host) to create and update Sablime data. Sablime tracks user identity via the "real uid" of the invoked command. To enable users to update the database, the commands are installed "setuid", so that the "effective uid" of the invoked command is the database owner (the Sablime administrator).

---

Web Sablime scripts (wedput, chgPasswd, etc.)

These generate the HTML pages seen by the Web Sablime user, based on information in the Sablime database. To update the Sablime database, they invoke host Sablime commands as needed.

Web Sablime setuid utilities (sabexec, sabpasswd)

These change the permissions (real and/or effective uid) under which other processes operate. The major utility (sabexec) arranges that Web Sablime scripts operate under the permissions of the remote user's local Unix login. The minor utility (sabpasswd) gives users limited write access to the Web Sablime password file, so they can set their own passwords.

Web Sablime logs (not shown)

The audit trail, error log, and security alert logs for sabexec. These are owned by "root".

Web Sablime password file

Contains passwords used to authenticate remote users accessing the Web Sablime application.

---

Web server process (httpd)

Serves HTML pages in response to requests from browsers and other remote clients. Authenticates remote users accessing Sablime data, using the designated password file.

Web server configuration file (httpd.conf)

Defines what user and group the web server process runs as. Defines special handling for particular directories: by requiring authentication (and designating a password file), by designating the directory as CGI-enabled, or by defining an alias for the directory. The Web Sablime application defines seven aliases, designates two directories as CGI-enabled, and marks one directory as requiring authentication.

Web password tool (htpasswd)

The utility for administering web password files; this is part of the web server software.

---

Java Runtime Environment (JRE)

Executes Java applications (e.g. SabMerge) on the client. Can (and should) be configured to execute Java applets in the browser, replacing the browser's native Java Virtual Machine. Must be installed on the client by the remote user.

Web Sablime Java Toolkit

Enables Web Sablime to manipulate client-side copies of Sablime data files. Installed automatically when needed.

Configuring Web Sablime

• Assigning roles to particular logins
• Identifying locations for existing utilities and new files

Preassigned Roles

System administrator ("root")

Creates & administers logins on the host. Installs Web Sablime. Owns the sabexec utility. Owns and monitors the Web Sablime log files. Can be assigned any or all of the configurable roles.

Sablime administrator

Owns and maintains the Sablime databases, host Sablime commands, and Web Sablime scripts. The wsab_install script infers this identity from the Sablime bin directory (SABHOME - see below). Should not be assigned any of the configurable roles.

Configurable Roles

Web server administrator

Administers (configures, restarts) the web server. This user should own the configuration file httpd.conf and the directory that contains it.

Web server logid

The login that the web server process actually runs as. This must be the same as the web server administrator unless the web server administrator is "root".

Web password administrator

Owns and administers the Web Sablime password file. Creates & administers entries in the Web Sablime password file, using htpasswd, for users who cannot log in to the host.

Locations

Sablime bin directory (SABHOME)

The top Sablime directory, containing the host commands such as edput. The Web Sablime installation software is in SABHOME/web/root_install.

Web server configuration directory

The directory containing httpd.conf.

htpasswd

The web server's password maintenance utility. This is often located in a sibling directory of the web server configuration directory.

perl

The perl interpreter. Web Sablime requires version 5.004_01 or later. Some platforms come with perl preinstalled, e.g in /usr/bin or /usr/local/bin. An up to date version can be downloaded from http://www.perl.com.

cc

An ANSI C compiler. Most current C compilers support ANSI C.

Web Sablime password file

You can specify an existing web password file, or the location where a new web password file is to be created.

root installation directory

The directory where the Web Sablime setuid utilities and logs will reside. This will be owned by root and must be somewhere where root can write. (Because many sites use file servers, root cannot necessarily write to just any directory.) The default is SABHOME/web/root_install.

Recommended Configuration

Web server administrator	root
Web server logid	A restricted login, e.g. "nobody"
Web password administrator	root, or a trusted individual login other than the Sablime admnistrator

By a "trusted individual login" we mean a login belonging to a trustworthy individual (as opposed to, for example, a "group" login, to which more than one person has access).

Other Configurations and Their Security Implications

Web server administrator	A trusted individual login other than the Sablime admnistrator
Web server logid	Same login as web server administrator
Web password administrator	Same login as web server administrator

This configuration is safe (only) to the extent that the web server administrator is indeed trustworthy and that no other user can gain access to the web server administrator account.

Do not assign any of the configurable roles to the Sablime administrator. The Sablime administrator controls the contents of the Web Sablime scripts. Adding to this the ability to run sabexec at will (as the web server logid can do) or to set (other users') Web Sablime passwords, in effect lets this administrator run any command as (almost) any user (though not "root", and not without leaving an audit trail -- see the following sections). Such a concentration of power is undesirable and unnecessary.

Web Sablime and System Integrity

Will Web Sablime let unauthorized users onto my system?

Data transmitted by Web Sablime (including passwords) is subject to "snooping" by suitably-equipped users on the network. An intercepted Web Sablime password can do limited harm, provided it only works with Web Sablime. Warn your users not to use their system password as their Web Sablime password.

What keeps sabexec from being misused?

Several safety restraints are built into sabexec:

• sabexec can only be invoked by one user (the web server logid)
• sabexec will only execute scripts in a particular directory (the basedir, at SABHOME/web/wsab), and owned by a particular user (the Sablime administrator)
• sabexec will not execute any script as root, or as any other user with uid < 100. (This number is configurable.)
• sabexec will not execute any script unless it can log the request (see Monitoring Web Sablime, below).
• The environment variables REMOTE_USER, REMOTE_ADDR, PATH_INFO, PATH_TRANSLATED must all be set and nonempty. PATH_INFO and PATH_TRANSLATED must point to the same script, and REMOTE_USER must be a valid login on the host
• basedir and the script to be executed must be owned by the Sablime administrator
• script and basedir must be write-protected (555 or 755)
• script must not be setuid or setgid
• script must be readable and executable by remote user's login
• sabexec must execute the script with basedir as its current directory

The Sablime administrator, web server logid, basedir, and log file locations are all specified when sabexec is compiled.

What if the Sablime administrator disables some of these restraints before asking me to install the software? Could I even tell?

For your peace of mind, the checksums for the source files sabexec.c and sabpasswd.c, and for the installation script wsab_install, are contained in the files themselves, and are published at the Sablime product site, at http://www.bell-labs.com/project/sablime/v60u3/chksums.html. If the computed, internal and published checksums all match, you can be confident you are dealing with unaltered software.

You can also download this part of the software directly from the Sablime product site, if you choose.

What about client-side security? A rogue Web Sablime java tookit could delete or alter practically any file on the client.

The Web Sablime java toolkit is digitally signed, so it cannot be altered without invalidating its certificate.

Monitoring Web Sablime

sabexec.alert

Attempts to use sabexec improperly are normally caught and logged to sabexec.alert. The log records the user invoking sabexec, the remote user id, the script name, and the time of the attempted access. It is wise to monitor this log for any activity, and investigate each attempted access reported.

sabexec.log

The sabexec.log is the main audit trail for usage of sabexec. For each access granted, the log records the user invoking sabexec, the remote user id, the script name, and the time of the access. In case you suspect sabexec is being used to get improper access to users' accounts, check the time of the incident against the log. Improper use may indicate that the user's web password has been compromised, or that the Sablime CGI scripts have been tampered with.

sabexec.err

Error messages reported to the user by sabexec are also logged to sabexec.err, together with the user name, script name, and time of the access. Most such errors indicate environmental problems fixable by the Sablime administrator.

Wrap Up