Multi v2.0
What is Multi?
Multi is a secure and configurable way to run
CGI binaries on a WWW server.
Multi is a wrapper for CGI execution. To create a secure environment,
Multi will:
- Confirm the CGI can be run.
- Compare the CGI with the configurable Multi rule set.
- Reduce its privileges to a secure level.
- Run the CGI at the secured level.
- Do a configurable amount of logging.
Why Multi?
Until now, the only way to run secure CGI binaries was to
submit them for review and installation. Every minor
modification took additional time and resources to
approve. Many sites disallowed CGI binaries to be run at
all because of the inconvenience and risks. Now there is
Multi. Once Multi is configured, CGI
binaries can be created, modified, and executed without
special assistance or security risks.
The Multi concept of security
A system without Multi can only execute a CGI with
the permissions which the web server itself runs at. A
single insecure binary could violate system integrity.
Multi gains its security by extending the multiuser
UNIX environment into the CGI paradigm. Each CGI is
executed with the permissions of a special user ID. Every
user ID has unique privileges and restrictions. These
privileges and restrictions allow a CGI to work in an
isolated environment which can not be accessed by the Web
Server itself, nor other CGI binaries. Likewise, a CGI is
restricted to a specific ID, so it can not overwrite files
it is not permitted to.
A few of the Multi security precations
- Check for valid username.
- Removal of all groups that might have been added as a
result of the httpdrunnign the cgi.
- Check to make sure user's shell is in /etc/shells.
- Recursive symlink checks.
- Invalid characters, also restricted characters in CGI pathname.
- CGI privlidge checks.
- Configurable amount of logging, from none to extensive.
Using Multi
First, Multi must be install in the proper
directory where CGIs are run from on your server. It must
be install with owner root, and permissions set to
4755.
It is then ready to be used. Its calling convention is:
http://servername/location_of_multi?location_of_CGI_to_run
and example is:
Parameters can be passed to the CGI that Multi runs
by adding them to the end of the URL that calls Multi,
separating them by "+";
The Multi Configuration File Overview
The configuration file begins with global options. These
are options that will be applied to the entire system
unless individually overridden. The second part of the
file contains directory segments and global overrides.
Each directory is specified via the directory
directive. After the directory is specified, options can
follow, which override the default options. If a user
runs a CGI that is not not in a directory that that is
specified as "allowed", then Multi will return an
error message.
Configuration file directives
- homedirs
- This option can only be used in the default/global
section of the configuration file. With this option
enabled, users may specify a path to Multi that
start with a ~ such as:
http://servername/cgi-bin/multi?~nirva/public_html/Projects/multi/cgi
This will use the username that is between the ~ and
the first / to determine all the necessary information.
The home directory and UID information comes from
/etc/passwd. When this option is taken advantage of,
the UID that is used to run the CGI is of the owner of
the directory that the CGI is in.
- userdir directory_name
- This option is another that may only be used in the
default/global section of the configuration file. This
option works along with homedirs. The
directory_name that is passed to this option is
inserted right after the first / after the username. For
example, if userdir public_html and
homedirs were in the configuration file, the
following URL was given
http://servername/cgi-bin/multi?~nirva/Projects/multi/cgi
the following file would be executed as the CGI
~nirva/public_html/Projects/multi/cgi
- directory
- Used to allow usage of CGIs in a directory. The
following wild cards can be used:
- *
- Replaces a group of arbitrary characters until the
next character after the * is found
- ?
- Replaces any 1 (one) character.
- %u
- Works exactly like *, except it uses what it finds as
the username of the person running the CGI and grabs the
UID to run the CGI as from the passwd file.
- %cX
- This is will be replaced by 1 (one) character. That
character will then be matched to the username's Xth
letter. If they do not match, it throws out the CGI's
path as being invalid.
- log options
- Sets the level of logging. Options can be added together
by specifying multiple options after log separated by whitespace.
Options are:
all |
Logs everything |
none (default) |
No logging |
url |
Logs the URL of the CGI that was accessed successfully. |
failure |
Logs all failures. |
symlink |
Logs the URL of the CGI which included a symlink in its path and
was successfully accessed. |
- uid the_uid
- sets the UID to run CGI in to the_uid
- gid the_gid
- sets the GID to run CGI in to the_gid
- symlink option
- Set how symlinks are to be handled. Default is
always. Options are:
always |
Always follow symlinks. |
never |
Never follow symlinks. |
ownersmatch |
Only follow symlinks if the owners match. (recursively) |
- badchars str1:str2:...:strN
- Set what substrings or characters are invalid to use in
CGI paths. Each string is separated by a ":". Common
examples would be "/../", "/./", and "\".
- allowroot
- Normally, root is not allowed to run CGIs through multi, this allows it.
Sample Multi configuration file
multi.conf
badchars /../:/./:\:~
uid www
gid private
homedirs
userdir public_html
directory /home/%c1/%u/public_html
symlink never
log all
gid users
directory /staff/%u/public_html /staff/adm/%u/public_html
symlink ownersmatch
log failure
gid staff
directory /public_html
symlink always
allowroot
Explanation
- The first 5 lines are defaults. They will used for
all CGIs unless something overrides them.
- Line 4 allows user to use the ~user convention. Line
5 inserts public_html after their username.
- The 7th line allows users to run CGIs from
/home/%c1/%u/public_html* as long as the %u is a valid
username and the subdirectory of the user directory is
one letter long and matches the first letter of their
username. The UID used here is from the %u.
- Lines 8-10 override or set new options for that one
directory.
- Line 12 sets up 2 new directories with lines 13-14
as new or overriding-default options. The UID is used
from the %u in both directories. If one or neither did
not have a %u, it would use the default, which is user
"www".
-
Line 16 sets up a directory that is always run as UID
www and GID private. The last 2 lines
allow CGIs to be run as root, and to always follow
symlinks in /public_html.