IBM HTTP Server Security FAQs¶
Other resources¶
For questions about address application level vulnerabilities related to IBM HTTP Server, see vulnerabilities.html
Filesystem permissions for IHS¶
This FAQ primarily addresses unix systems. In modern releases, the installer creates most files with 0755 permissions.
Because IHS sometimes runs under multiple userids, changing filesystem permissions can be complicated. This FAQ only covers the following two scenarios:
IHS installed by root and started as root. This is the recommended and preferred configuration on unix systems.
IHS installed by non-root user X and started by non-root user X.
Other configurations require more lengthy/meticulous configuration. Those configurations include root-owned IHS started by a semi-privileged or a semi-privileged user installing IHS started by an unrelated unprivileged user.
IHS started by root¶
The issues for an instance of IHS started by root primarily involve
resources needed at request processing time, after IHS has switched to
the ID specified with the User
directive. We will refer to this as the
configured ID. Note that all of the requirements below are met in the
default configuration.
The root (UID 0) user implicitly has full control of the installation root.
There is generally no need to change ownership of any product files or configuration.
The configured ID needs to be able to read any static content it will serve.
The configured ID needs to be able to execute any CGI content it will serve.
The configured ID needs to be have search (execute) access to all directories between / and the directory containing static content.
The configured ID needs to be able to read and write to mod_disk_cache's CacheRoot. There is no default CacheRoot.
The configured ID does NOT need write access to any IHS binaries, contents, directories, or logs not previously mentioned.
The configured ID does NOT need read access to any IHS KeyFile.
If using the WAS Plug-in:
plugin-key.* needs to be readable by the configured ID if SSL is used and plugin-cfg.xml is ever reloaded on the fly (RefreshInterval != 0 and plugin-cfg.xml updated at runtime). In environments where security is paramount, disable this reloading.
The optional IHS Administration Server, used by WAS to start/stop IHS and push plugin-cfg.xml and plugin-key.* to remote webservers, requires that plugin-cfg.xml be group-writable and be owned by the admin servers own group. The Admin Server should always be started by the same userid that starts IHS. In environments where security is paramount, do not use the IHS Admin Server. This configuration also uses a shared group, and group write access, to the $IHSROOT/conf directory to allow httpd.conf propogation. Obviously the selection of shared group and its membership needs to be tightly controlled.
Changes to filesystem permissions are not preserved during fixpack or interim fix application.
Generally the mechanism by which the configured ID has read or execute permissions to the filesystem are via the other/world permissions on files owned by root. While it may technically possible to use a shared group for this purpose, it has not been considered/designed/tested by IBM.
IHS started as non-root¶
When IHS is started by a non-root ID, for the purposes of this document it's assumed that this user ran the installation and has ownership of all files in the installation root.
The non-root ID user implicitly has full control of the installation root.
There is generally no need to change ownership of any product files or configuration.
Generally, no other ID will require filesystem read or write beneath the installation root.
Changes to filesystem permissions are not preserved during fixpack or interim fix application.