FrontPage 2002 Server Extensions Security Under UNIX
|Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
In addition to the Microsoft® Windows® operating system with Internet Information Services (IIS), you can also use Microsoft FrontPage 2002 Server Extensions on the UNIX platform, running Apache Web server with the FrontPage Apache patch. To secure your Web site, you use the built-in security features of UNIX, Apache, and FrontPage 2002 Server Extensions.
UNIX security model
The Apache Web server maintains a list of users who have permission to use the Web server. This access file list is specific to the Web server and is separate from the list of users and groups who can log on to the computer interactively.
The Web server access file contains names and passwords for each user, and the list of files and Common Gateway Interface (CGI) scripts that each user is allowed to access. On Apache servers, the user name and password file is called service.pwd, the group file is called service.grp, and the access file containing the information about which users can access files and CGI scripts in the .htaccess directory is named .htaccess.
In FrontPage 2002 Server Extensions, there are two levels of security. First, the .htaccess files in the _vti_bin, _vti_aut, and _vti_adm directories tell Apache which users can execute the shtml.exe, author.exe, and admin.exe CGI scripts. Second, the FrontPage 2002 Server Extensions code checks the roles list to see if the authenticated user has permission to execute the requested FP-RPC command.
Multiple access files are often stored on a Web server. Each access file provides security for the directory containing it and for any subdirectories that do not contain their own access files. By creating access files at all levels of the Web server, users with varying levels of permissions can be given access to different areas of the server.
The Web server runs as a UNIX account, usually www, which limits which files the Web server can access. Any process that the Web server runs and any files that it opens must be available under the permissions of the same UNIX account. This arrangement can cause a security problem in a multihosted environment, because one user's CGI script might read files in another user's content area on the server. This problem is compounded when write access is supported, as it is with the FrontPage 2002 client. If a user's CGI script has sufficient permissions to write to a file in the user's own content area, the CGI script could write or overwrite files in other users' content areas.
To address this security issue (which is common to all CGI scripts, including the FrontPage 2002 Server Extensions), FrontPage 2002 Server Extensions uses an SUID approach, so that the FrontPage 2002 Server Extensions code always runs as the UNIX account that owns the particular content area. For more information, see the FrontPage Apache patch section below.
Supported authentication methods
The Apache Web server supports Basic Authentication out of the box, and FrontPage 2002 Server Extensions support remote administration when Basic Authentication is used. When the server uses Basic Authentication, the Web browser (or the FrontPage 2002 client) prompts the user for a user name and password. The user name and password are then transmitted in clear text. (Some Web servers use an encryption technique known as MD5, but FrontPage 2002 Server Extensions do not support this method.)
FrontPage 2002 Server Extensions use Basic Authentication because all firewalls and proxy servers support it. Because Basic Authentication transmits passwords across the network in an easily decoded format, however, it is easy for network spies to steal passwords that are sent in this manner. If you are concerned about security, consider using Secure Sockets Layer (SSL) to encrypt all communications to and from your Web server.
Controlling user access
In FrontPage 2000, three types of users were defined for every FrontPage-extended web: administrators, authors, and browsers (site visitors). For FrontPage 2002 Server Extensions, there are now five roles for users by default: Browser, Contributor, Author, Advanced Author, and Administrator. As in FrontPage 2000, permissions for these roles are cumulative for example, all Authors also have Browser permissions.
Under UNIX, FrontPage contains four executable CGI scripts:
Admin.exe for administrative tasks
Author.exe for authoring webs
Shtml.exe for browse-time components such as form handlers
Fpadmcgi.exe for advanced administrative tasks
These scripts are installed in the /Usr/Local/Frontpage/Version5.0/Exes/ folder. FrontPage performs all authoring and administrative tasks by sending HTTP POST requests to the Apache Web server, which then invokes these scripts. There are also three directories created below the root of every FrontPage-extended web to contain .htaccess files, which determine which users are allowed to run the executables. These directories are:
_vti_bin, which stores permissions for shtml.exe
_vti_adm, which stores permissions for admin.exe and fpadmcgi.exe
_vti_aut, which stores permissions for author.exe.
The _vti_adm and _vti_aut subdirectories are within the _vti_bin directory, as shown in the following example:
/FrontPage-extended web root
FrontPage 2002 Server Extensions maintain these .htaccess files when you add and remove users for a FrontPage-extended web. These .htaccess files refer to a user/password file and a group definition file. The user name/password list for each FrontPage-extended web with unique permissions is stored in _vti_pvt/service.pwd, and the group definitions are stored in _vti_pvt/service.grp. FrontPage-extended webs that inherit permissions from their parent web use their parent web's service.pwd and service.grp files. FrontPage 2002 Server Extensions maintain the service.pwd and service.grp files automatically when you add and remove users for a FrontPage-extended web. For more information, see the Access Files section below.
Securing Web content
Setting secure permission modes for files and directories in a customer's content directory is necessary to maintain Web server security. All files and directories must be owned by the customer's user identifier/group identifier to prevent other customers on the same server from being able to modify those files. The following table shows how Owsadm.exe sets file modes when you run it to configure a virtual server with FrontPage.
Settings to use
Single UNIX account per customer
rw- r-- r--
rw- r-x r-x
--- -w- -w-
For example, when configuring a virtual server with FrontPage, you run Owsadm.exe with the following options (note that this example assumes that multihosting is being used, and that the virtual host name is www.host.com):
owsadm.exe -o install -p www.host.com -servconf /usr/local/www/conf/httpd.conf -xu unixuser -u webusername -pw webpassword
In this example, unixuser is the Unix account of the customer that owns this virtual server. Each customer must have his own UNIX account if you want strong security. All files and directories under the root content directory for the virtual server change ownership (chown) to this account and the account's group (by using chgrp).
Also, webusername and webpassword are the user name and password that must be used when remotely accessing the web site by way of the FrontPage 2002 client or when accessing HTML Administration Pages for the virtual server.
Later, you can use Owsadm.exe to change ownership and change mode (chmod) of existing content files in a FrontPage-extended web if necessary.
By default, a 022 umask is used when FrontPage 2002 Server Extensions are used to create new Web pages and other files. To set a custom umask, you must edit and recompile the source file for the FrontPage Apache patch, fpexe.c. Because you must edit the umask in the patch itself, you can only change the umask value for an entire server you cannot set a separate umask value for each web. To change the umask, open the fpexe.c file and search for the following line:
Owsadm.exe uses the umask that is set for the shell in which Owsadm.exe is run.
On Apache Web servers, an access file contains security-related directives that control which users and groups have access to the content on a server. An access file can also contain directives that specify which IP addresses have access to content.
The global access settings for the Web server are contained in the access sections in the httpd.conf file. Per-directory access files (named .htaccess) can be placed in directories on the Web server to implement per-directory access control. FrontPage 2002 Server Extensions security uses and relies upon .htaccess files that are placed in the content directories. FrontPage 2002 Server Extensions assume you do not also try to control access to FrontPage-enabled webs by using httpd.conf. You must enable .htaccess files in Apache by using the AllowOverride setting in httpd.conf, otherwise the default FrontPage security will not work and your Web server will be insecure. The default Apache setting for AllowOverride is All, which is the recommended setting for FrontPage-extended virtual servers. AllowOverride must allow at least AuthConfig, Limit, and Options.
Access file settings
FrontPage 2002 Server Extensions rely on .htaccess files to add FrontPage-extended web visitors with the proper permissions to the Web server account list, and to protect content and programs in FrontPage-extended webs.
FrontPage 2002 Server Extensions create a directory named _vti_pvt for the root web and for each subweb. In each FrontPage-extended web with unique permissions, the _vti_pvt directory contains the following two files:
Service.pwd contains the list of users and encrypted passwords for the FrontPage-extended web
Service.grp contains the list of groups, and the users within each group
The .htaccess file in the _vti_bin directory controls access to the browse-time FrontPage 2002 Server Extensions program Shtml.exe. If all users have browse permission, this setting is specified in the access file. Otherwise, the access file points to a list of users and groups with browse access. A separate .htaccess file in the _vti_adm directory sets permissions for the administrative program, Admin.exe. A third /htaccess file in the _vti_aut directory sets the permissions on the authoring program, Author.exe.
When you add a user to a role by using the FrontPage 2002 Server Extensions administration tools, FrontPage 2002 Server Extensions add the user's name and password to the single Service.pwd file and to the appropriate group in the service.grp file pointed to from the .htaccess files stored in the _vti_bin, _vti_aut, or _vti_adm directories. When an IP address restriction is set on browse access to an FrontPage-extended web, this restriction is added to the _vti_bin directory access file.
The set of access files for the non-CGI _vti directories created by FrontPage 2002 Server Extensions on an FrontPage-extended web is illustrated in the following table.
Web directories or content
Runtime Access List
Miscellaneous Access List
FrontPage Apache patch
FrontPage supplies a patch to the Apache Web server that has two purposes: it eliminates the need to update the httpd.conf file when a subweb is created, and it securely enables the SUID functionality that the FrontPage scripts run as the UNIX account that owns a particular FrontPage web.
The patch to the Apache Web server intercepts each call that the FrontPage client makes to the server extensions executable files. It then performs security checks, sets user ID to the owner of the Web site (thus requiring SUID/SGID operation of the server extensions and the Web content), and invokes a central copy of the server extensions executable files.
The FrontPage Apache patch was optional for FrontPage 2000 but is required for FrontPage 2002 Server Extensions, because it is more secure and allows users to create subwebs remotely.
Apache patch security strategy
The FrontPage Apache patch consists of two parts:
The FrontPage Apache module, which intercepts requests from the FrontPage client to the FrontPage 2002 Server Extensions executable files, performs security checks, and redirects the request to the fpexe stub program, which is set to SUID root. By intercepting each request within the server itself, no script alias is required.
The fpexe program, which accepts authoring requests from the FrontPage Apache module, performs additional security validation, changes the user ID of the Web server process to the owner of the FrontPage-extended web being authored, and then invokes the central copy of FrontPage 2002 Server Extensions executable files.
The fpexe stub program must be set SUID to root in order for it to change user IDs of the Web server process to the owner of the web. For that reason, numerous security checks are performed in order to prevent this stub program from being exploited. Checks are performed to validate the following:
Proper ownership and permissions are set for the fpexe stub program and its directory.
Proper ownership and permissions are set for the server extensions executable files and their directories.
The Web content area being authored has a valid user ID.
The Web content area being authored has a valid group ID.
Only the FrontPage 2002 Server Extensions CGI executable files are being executed, and not other CGI scripts on the computer.
The environment variables (including the path) are cleaned and passed only if the variable is on an approved list.
FrontPage 2002 Server Extensions executable files are being invoked only by the Web server.
A 128-byte key value is passed to the fpexe program and validated, ensuring that only the Web server is able to run fpexe.
The 128-byte key value is generated dynamically when the Web server is initialized, and stored for validation purposes in a suidkey.* file. This file can be read and written only by "root" and is stored in a directory that is readable only by "root." The suidkey.* file can be written with root-only permissions because the Web server process runs as "root" during initialization, and does not switch to another user ID (such as "www") until after initialization is complete. The suidkey.* file name suffix is the process group ID of the Web server.
The contents of this dynamic key value are generated during Web server initialization based on a permutation of the output of the process status (ps) command, and are then marked as exclusive or (XOR'ed) with the contents of an administrator-controlled custom key file stored in /usr/local/frontpage/version5.0/apache-fp/suidkey. This custom key file must exist, be owned and readable only by "root," and contain at least eight bytes of data.
Because programs with user ID set to "root" are of concern to server administrators, Microsoft makes the source code of the FrontPage Apache module and the fpexe stub program available for review. The source code is extensively commented with an explanation of the checks that are performed and recovery actions to take if an error denoting an insecure configuration is logged by the FrontPage Apache module or fpexe. As part of your server's maintenance, change the contents of the custom key file regularly when restarting the server. This step protects the key value.
Note The SharePoint™ Team Services Administrator's Guide includes the source code for the FrontPage Apache module and the fpexe stuff program. For more information, see Source Code for fpexec.c and Source Code for the FrontPage Apache module .
How the key is validated
When the FrontPage Apache module processes a request to invoke the FrontPage 2002 Server Extensions executable files, the module performs preliminary validation of the request and redirects the request to the fpexe stub program. The 128-byte key value generated when the server was initialized is passed to fpexe through a pipe and thus is not visible in the program environment. The 128-byte key value is read by fpexe from the pipe, and then compared to the contents of the dynamically generated suidkey.* file that was created when the Web server was initialized.
Because the user ID of fpexe is set to "root," it has access to the contents of the suidkey.* file. If the suidkey.* file has correct permissions (readable only by "root" in a directory readable only by "root"), and if the 128-byte key value matches, then fpexe performs additional checks to validate the user ID, group ID, and ownership of the target FrontPage 2002 Server Extensions executable files.
If all checks pass, then fpexe switches the user and group IDs of the server process to those of the Web content owner, and then runs the FrontPage 2002 Server Extensions executable files. If any of these checks fail, an error is written to the Web server log and the server extensions are not run.
Note that the FrontPage Apache module's security checks do not replace the Web server's .htaccess file security system. Both systems work together to ensure security for the FrontPage-extended web. The Web server's .htaccess security protects remote access to the Web content by validating that the user of the FrontPage 2002 Server Extensions is a registered site visitor, author, or administrator of the web. In addition to this normal level of security checking, the FrontPage Apache module's security checks ensure that the fpexe program is not used to gain unauthorized root access to the Web server.
Setting FrontPage 2002 Server Extensions to SUID/SGID
When you use the FrontPage Apache patch, the execute permissions of the FrontPage 2002 Server Extensions executable files are automatically changed to Set User ID/Set Group ID (SUID/SGID). This setting forces the server extensions to be executed with the file-system permissions of the owner of shtml.exe, author.exe, and admin.exe. When suitable permissions for each customer's content area are applied, the FrontPage 2002 Server Extensions (and any other CGI scripts) for one customer are prevented from writing to the content areas of other customers.
Setting the FrontPage 2002 Server Extensions to SUID/SGID provides two benefits:
It prevents users who have telnet access to the Web server computer from modifying content in a web that they do not own.
It provides an extra level of operating system security on top of the security built into FrontPage.
Setting the FrontPage 2002 Server Extensions to SUID/SGID for the owner of each FrontPage-extended web is the recommended configuration for the FrontPage 2002 Server Extensions on UNIX servers. Existing installations of the FrontPage 2002 Server Extensions earlier than version 3.0 should be upgraded to use SUID/SGID operation of the server extensions and unique ownership of the Web content. New installations of the FrontPage 2002 Server Extensions that are performed with the Owsadm utility or the fp_install.sh installation script by using the FrontPage Apache patch automatically configure the server extensions for SUID/SGID operation.
The FrontPage 2002 Server Extensions do not require root access at any time. However, the Owsadm utility and the fp_install.sh installation script should be run as "root," because they set execute privileges of the extensions to SUID. Because fp_install.sh is written as a shell script, you can review it before running it on the Web server. Also, if you want the Server Administration Pages to work, a special copy of fpadmcgi.exe (two copies of this file are installed at Setup) must be run as root.
Other security issues
When you work with Web servers, you must be aware of other possible entry points to your content. For example, you can secure all of your users, and set permissions on files, but if you allow users to perform certain operations, such as posting by way of File Transfer Protocol (FTP) or using Telnet to perform administration tasks, you might expose your Web server to security threats. With the FrontPage 2002 Server Extensions and the FrontPage Apache patch, many of these concerns are handled for you.
Using FTP with FrontPage 2002 Server Extensions
You can use FTP and the FrontPage 2002 Server Extensions on IIS and on Apache servers that are running the FrontPage Apache patch (apache-fp); however, it is not recommended. If you do want to use FTP with FrontPage 2002 Server Extensions, be sure to configure the FTP server to disallow write access to any directory beginning with _vti, so that these directories and their contents cannot be deleted or renamed. Also, be sure to configure the FTP server so that when a user connects to the server by way of FTP, the directory root in his or her FTP client is the same as the content root for his or her Web site.
Using Telnet with FrontPage 2002 Server Extensions
You can use Telnet and FrontPage 2002 Server Extensions on IIS and apache-fp servers, bearing in mind the same restrictions as for FTP.
Checking for changed permissions
The shell script, set_default_perms.sh, which is installed in the /usr/local/frontpage/version5.0 directory, sets the permissions for the contents of /usr/local/frontpage/version5.0 and all nested directories and files. After these permissions are set, FrontPage does not change them. However, if you suspect that the permissions on any /usr/local/frontpage/version5.0 files or directories have been changed, you can reapply the correct permissions by running set_default_perms.sh. This script takes no command-line arguments.
FrontPage 2002 Server Extensions support connectivity through firewalls. Depending on your configuration, you must make sure your firewall is open for the standard HTTP ports 80 and 443. When using a firewall, you must configure your Web sites with Basic Authentication.
Managing permissions manually
With FrontPage 2000 Server Extensions, you could bypass the built-in security management and set permissions manually on the content of a FrontPage-extended Web site. With FrontPage 2002 Server Extensions, the roles and permissions have been improved, and this functionality is no longer available.