The document discusses confining the Apache web server on Security-Enhanced Linux to reduce risks while maintaining functionality. The authors: 1) Define types and roles to control Apache processes and files, allowing Apache to perform required functions like serving web pages while restricting other access. 2) Tailor the Security-Enhanced Linux policy to specify allowed interactions between types, such as allowing the Apache server to read configuration files. 3) Demonstrate that Security-Enhanced Linux can confine commonly used applications like Apache through policy modifications, reducing risks from exploitation while still providing expected functionality.

1. Confining the Apache Web Server with Security-Enhanced Linux
Michelle J. Gosselin, Jennifer Schommer
mgoss@mitre.org, jschommer@mitre.org
Keywords: Operating System Security, Web Server Security, Access Control Policy
Abstract Introduction
Restricting the access of a web server to Commonly used applications, such as
system resources limits the potential damage web servers, are often vulnerable to attack.
caused to those resources through To prevent attacks from being successful,
exploitation of web server vulnerabilities. known vulnerabilities can be eliminated by
However, allowing the web server to access reducing application functionality or by
the required resources enables the web implementing fixes or patches within the
server to provide expected functionality. application source code. Reducing
This combination of denying unnecessary functionality is often not acceptable to users,
access and allowing required access results and implementing fixes requires the
in providing web server functionality while cooperation of the vendor and is typically in
limiting damage. reaction to damage that has already
To demonstrate this, we hosted the occurred.
Apache web server on Security-Enhanced An alternative is to reduce the level of
Linux, an operating system that enforces a risk by confining the application. Confining
mandatory access control policy. By an application means to control the
tailoring the Security-Enhanced Linux application's access to, and malicious
policy, we were able to control interaction damage to, system resources (e.g., processes
between the Apache web server and other and files).
processes and files on the system. The To adequately confine an application,
policy dictates that Apache is only allowed the operating system that hosts the
to display web pages and perform limited application must enforce a mandatory access
functions that support the display of web control policy as specified by the system
pages. security administrator. An example of an
This work demonstrates the following. operating system that provides mandatory
∑ Security-Enhanced Linux is capable of access control features is Security-Enhanced
supporting commonly used applications. Linux1[1][2][3][4].
∑ Security-Enhanced Linux can confine To demonstrate the feasibility of
applications so that a reduced level of confining an application without reducing
risk is achieved when making functionality, we hosted the Apache HTTP
applications available.
∑ Although confined, these applications
provide the functionality expected by
1
users. Linux is a registered trademark of Linus Torvalds.
The LSM-based Security-Enhance Linux prototype is
currently supported for kernel 2.4.17 and 2.5.2
with RedHat 7.1 or RedHat 7. 1. Red Hat is a
registered trademark of Red Hat Software, Inc.
1

2. Server2 on Security-Enhanced Linux and executable code as input into a form or guest
used features provided by Security- book. If the server executes that code, the
Enhanced Linux to confine Apache. server could cause damage to the system.
This paper describes Another type of script is a Server Side
1. potential damage caused as a result Include (SSI). An SSI is a file that can be
of exploitation of a web server, parsed by the web server to supply dynamic
2. Security-Enhanced Linux features, information for a web page, such as the
3 . how these features were used to current time and date. Executable shell
confine the Apache web server, and commands or an interface to CGI scripts can
4. how potential damage resulting from be included in an SSI. For example, an SSI
exploitation of the Apache web could include a statement such as <!--#exec
server is reduced while still allowing cgi="runme.cgi"-->. The web server would
Apache functionality. execute runme.cgi when it parsed the SSI. If
runme.cgi contained malicious code, the
Web Server Security Concerns web server could cause damage when
Sharing information and conducting running the code.
business via the World Wide Web has
Approaches to Reducing Risk
become a critical requirement for most
organizations. However, a web server that There are several approaches that can be
allows an organization to share information taken to reduce the risk associated with a
and conduct business could potentially be web server.
exploited to cause unauthorized One of the easiest methods of reducing
modification or destruction of that risk is to run the server as "nobody" [5].
information and other system resources. This can either occur when the server is
Through various attacks, such as buffer launched or whenever the server forks a
overflow attacks, a malicious user could process to handle a connection on port 80.
gain control of a web server process. Since However, once the server starts running as
web servers often run with enhanced "nobody", the system administrator has to
privileges, the user who gains control of the ensure that the server still has access to files
web server process possesses enhanced it needs access to by setting permissions
privileges that can be used to cause damage appropriately. This may result in granting
to the system. wider access to certain files than is desired.
Even if a malicious user cannot gain This approach also doesn't prevent access to
control of the web server process, scripts world-readable/writeable/executable
potentially allow users to direct the web directories and files, of which there are
server to perform a malicious action. A many on a typical system. If any of these
Common Gateway Interface3 (CGI) script executables happens to be setuid, it may be
accepts user input and submits it to the possible to obtain root privileges indirectly.
server for processing. For example, Another method of reducing risk is to
electronic purchasing forms and web site tighten the configuration of the web server
guest books are typically implemented and either restrict or turn off
through CGI scripts. Unfortunately, it is functionality[6]. For instance, the web
possible for a malicious user to enter server could be configured to deny the use
of SSI's or user-developed CGI scripts. This
2
Developed by the Apache Software Foundation eliminates vulnerabilities but also eliminates
(http://www.apache.org) functionality. It also requires the system
3
Specification at http://hoohoo.ncsa.uiuc.edu/cgi/
2

3. administrator to have knowledge of web However, they all suffer from administrative
server configuration details. overhead and provide no defense against
A third approach is to restrict the files ‘root exploit’ attacks that lead to unwanted
and processes the web server has access to. access. None of them deal with
The web server cannot damage files and vulnerabilities in the base server or in other
processes that are inaccessible. This can be services running on that server. They also
done using the chroot() system call. focus on controlling access of a process to a
chroot() changes the root of the file system file, but do not address access of one process
as it appears to the process. Any search for to another.
a file will start at this new root as if it were
“/”. This will cause, with appropriate Security-Enhanced Linux
choices being made as to directory structure, To more effectively address a wider
any other user files to disappear from the range of server concerns, the operating
viewpoint of the process. For the same system that hosts the web server must
reason though, the file structure containing enforce a mandatory access control policy as
the various system binaries will also become specified by the system security
inaccessible. This means that all of the administrator. One such operating system is
manifold utilities and libraries that web Security-Enhanced Linux.
servers need must be duplicated in the newly A general security policy configuration
rooted file structure. [10] is included with Security-Enhanced
Creation of a chroot() ‘jail’ does not Linux. This general policy contains Type
prevent root exploit attacks and barely slows Enforcement4 and Role-Based Access
down the malefactors when they succeed. Control (RBAC) components.
All it takes is to execute chroot() with the With Type Enforcement, types are
appropriate path. Even if the web server is associated with processes and files, and the
not running with root privileges, its policy defines allowed interaction between
enhanced privileges may be enough for the types5. For example, the policy could state
attacker to do some damage when it is that a process of type y_t is allowed to write
penetrated. to a file of type x_t.
Another approach addresses the dangers A security configuration uses Role
associated with CGI scripts. Wrappers, such Based Access Control by defining a set of
as suEXEC [7], cgi-wrap [8], and sbox [9], roles, and associating a list of types with
are called by the server to execute user each role6. A process executing with a
scripts rather than executing them directly. particular role must always be executing
These wrappers then perform functions with one of the associated types; the security
such as checking various system and file server will not permit it to transition to any
parameters, ensuring that only approved other type.
commands are called from the scripts,
enforcing resource-usage limitations,
changing the uid of the process to match the 4
Type Enforcement is a registered trademark of
uid of the script, and calling chroot().
Secure Computing Corporation.
However, the wrapper approach only 5
This differs from traditional Type Enforcement
addresses the CGI script concerns, and not where domains are associated with processes and
other web server concerns. types are associated with objects. Permissions are
The solutions above represent a defined for both pairs of domains and for domain-
type pairs.
reasonable attempt to deal with the problems 6
This differs from traditional RBAC where
of web-hosting on a Linux platform. permissions are associated with roles.
3

4. Three roles are defined in the base
security configuration.
∑ system_r is assigned to the user
identity for system-owned processes
and files (system_u),
∑ sysadm_r is assigned to system
administrators,
∑ user_r is assigned to ordinary users
Each user process starts with an initial Figure 1.
role assigned to that user, although
processes may change roles. Because of the flexibility of Security-
Roles and types are associated with a Enhanced Linux, it is possible for Security-
process or file through a security context7. Enhanced Linux to both support and confine
The security context labels the process or commonly used applications through
file with a user identifier, a role, and a type. modifications to the policy.
For example, when a user, John Smith, first
logs in, the security context of his shell is Policy Development Approach
jsmith:user_r:user_t. The security context of To demonstrate how the security
a process or file can change, or transition, as features of Security-Enhanced Linux can
required and as allowed by the policy. confine an application, we hosted an Apache
As previously stated, a general security web server on Security-Enhanced Linux and
policy configuration is included with tailored the policy to confine Apache. The
Security-Enhanced Linux. This policy is tailored policy addresses the web server
intended as a starting point for system concerns identified previously.
administrators to customize a policy to fit To implement an effective security
the security requirements of their system. policy for Apache - one that reduces risk to
The Security-Enhanced Linux an acceptable level while maintaining an
architecture and implementation simplify acceptable level of functionality - we took
policy changes by separating policy and the following approach in developing the
enforcement functions. As shown in figure policy:
1, an Object Manager receives requests for 1 . We became familiar with the
objects. The Object Manager queries a functionality provided by Apache.
Security Server to see if the policy permits We did this by reading user
the requested action. The Security Server documentation, inspecting Apache
reads the current system policy and source code, and running Apache
determines if the action is allowed or not. on Red Hat Linux 6.1.
The Security Server sends its decision to the 2 . We determined who should be
Object Manager, and the Object Manager allowed access to this functionality
enforces the decision. By separating the (e.g. who starts the application).
policy and enforcement, a change in policy 3 . Based on steps 1 and 2, we
does not require a modification to the postulated a high-level policy in
enforcement mechanisms. English for Apache.
4. We determined files installed with
7 Apache and their installation
Since files do not transition between types as
processes do, the role associated with a file has little locations by using the Redhat
function. Therefore, a default role of object_r is used Package Manager (RPM).
for files.
4

5. 5. We determined files accessed by - create and modify system web
Apache to provide functionality pages,
identified in step 1. - modify and execute system
6. Based on steps 3 and 4, we refined scripts,
the high-level policy. - specify password protection on
7 . We identified and defined roles system web pages and scripts,
and types to support the refined and
policy and indicated which roles - specify which files can be
where allowed to access these accessed by system scripts
types. ∑ Users are allowed to
8 . Based on the refined policy, we - send requests for web pages to
determined allowed interaction the Apache server,
between types.
- modify user web pages,
9 . We included these allowed
- modify and execute user scripts,
interactions in the Security-
Enhanced Linux policy using the - specify password protection on
Security-Enhanced Linux policy their web pages and scripts, and
language. - specify which files can be
1 0 . We ran Apache on Security- accessed by user scripts.
Enhanced Linux and performed ∑ Script processes are allowed to
both functionality testing and - execute script interpreters and
security testing. If a test failed, we libraries
returned to step 5. - read, write, and append specially
marked files.
Confining Apache For Apache to provide its functionality,
we determined that Apache requires access
Apache is a full-featured, open source
to various files and modified the high-level
web server that is packaged with RedHat
policy to allow the Apache server to do the
Linux. Apache's primary role is to display
following:
web pages to users requesting the web
pages. To properly display these web pages, ∑ send and receive messages to and
Apache handles many of popular web from the network
technologies such as CGI scripts and SSIs. ∑ bind to port 80
The high-level policy we stated for ∑ read web configuration files located
Apache is: in /etc/httpd/conf
∑ The Apache server is allowed to ∑ read and append to web log files
- accept user requests for web located in /var/log/httpd
pages, ∑ execute system libraries and Apache-
- read web pages, specific libraries
- execute scripts, ∑ call suEXEC prior to executing user
- check password protection on scripts if Apache is configured to do
web pages and scripts, and so.
To support this high-level policy, we
- display web pages back to the
defined a role for the web administrator
user.
called httpd_adm_r. We also defined new
∑ The system boot process is allowed
types required to control Apache processes
to start the Apache server.
and files. Apache processes and files and
∑ The web administrator is allowed to
5

6. their assigned types and roles are listed in
table 1.
6

7. Process or File Type Role
Apache daemon (server process) httpd_t system_r
System web pages (.html or .htm files) httpd_sys_content_t object_r
User web pages (.html or .htm files) httpd_user_content_t object_r
System script file httpd_sys_script_t object_r
User script file httpd_user_script_t object_r
Files that provide web password protection on httpd_sys_htaccess_t object_r
system directories
Files that provide web password protection on httpd_user_htaccess_t object_r
user directories
Apache configuration files located in httpd_config_t object_r
/etc/httpd/conf
Apache log files located in /var/log/httpd httpd_log_files_t object_r
Libraries included with Apache httpd_modules_t object_r
Apache executable file httpd_exec_t object_r
Web administrator shell process httpd _admin_t httpd_adm_r
System script process httpd_sys_script_process_t system_r
User script process httpd_user _script_process_t user_r
Files that can be read by system scripts httpd_sys_script_r_t object_r
Files that can be read and written by system httpd_sys_script_rw_t object_r
scripts
Files that can be appended by system scripts httpd_sys_script_a_t object_r
Files that can be read by user scripts httpd_user_script_r_t object_r
Files that can be read and written to by user httpd_user_script_rw_t object_r
scripts
Files that can be appended to by user scripts httpd_user_script_a_t object_r
suEXEC executable httpd_suexec_t object_r
suEXEC process httpd_suexec_process_t system_r
Table 1
7

8. System System User User
Config Log
Scripts Web .htaccess Web Scripts
Files Files
Pages Pages
initrc
User Shell
Web Daemon user_t
Web Admin Shell
httpd_admin_t httpd_t
Network,
Port 80
suEXEC
httpd_suexec_process_t
Libraries
System Script User Script
httpd_sys_script_process_t httpd_user_script_process_t
Script
Interpreters
System Key User
Script- Read Read/Modify Script-
Accessible Accessible
Files Modify Execute
Files
Figure 2.
∑ connect to the network and bind to
After defining these types, we used the port 808,
Security-Enhanced Linux policy language to ∑ read files of type
specify a "formal" policy that implemented httpd_sys_content_t (system web
the high-level policy. This "formal" policy pages) or httpd_user_content_t (user
is described below and is depicted in figure web pages)
2.
The policy states that a process of type
8
httpd_t (the Apache daemon) can This is actually allowed in the general security
policy that is distributed with Security-Enhanced
Linux.
8

9. ∑ execute files of type written by system scripts), and
httpd_sys_script_t (system scripts) httpd_sys_script_a_t (files or
and type httpd_user_script_t (user directories that can be appended by
scripts) system scripts).
∑ read files of type ∑ read and write files of type
httpd_sys_htaccess_t (files that httpd_config_t and httpd_log_files_t
provide password protection on (the web configuration files and web
directories containing system web log files)
pages and scripts) and The policy allows a user to
httpd_user_htaccess_t (files that ∑ send requests to port 80 either
provide password protection on locally or via the network9,
directories containing user web ∑ modify files of type
pages and scripts) httpd_user_content_t (user web
∑ read files of type httpd_config_t pages)
(web configuration files) ∑ modify and execute files of type
∑ read and append files of type httpd_user_script_t (user scripts)
httpd_log_files_t (log files) ∑ create files of type
∑ execute files of type lib_t (system httpd_user_htaccess_t (password
libraries) and httpd_modules_t (httpd protection files)
libraries) ∑ create files of type
∑ execute files of type httpd_suexec_t httpd_user_script_r_t (files that can
The policy allows files of type initrc_t to be read by user scripts ),
execute files of type httpd_exec_t. This httpd_user_script_rw_t, (files that
allows the boot process to run the Apache can be read and written by user
daemon. scripts), and httpd_user_script_a_t
The policy allows a web administrator (a (files that can be appended by user
user with the httpd_adm_r role) to change scripts).
the context of his shell to httpd_admin_t. When a script is executed, the following
The policy allows a process with this security context transitions automatically
context to take place:
∑ execute files of type httpd_exec_t ∑ When the daemon executes a system
(the Apache daemon) script (httpd_sys_script_t), the
∑ modify files of type process type transitions to
httpd_sys_content_t (system web httpd_sys_script_process_t.
pages) ∑ When the daemon executes suEXEC
∑ modify and execute files of type to invoke a user script
httpd_sys_script_t (system scripts) (httpd_user_script_t), the process
∑ create files of type type transitions to
httpd_sys_htaccess_t (password httpd_suexec_process_t. suEXEC
protection files) changes the user id to the user id of
∑ create files of type the script owner and the role of the
httpd_sys_script_r_t (files or process to user_r10. The process
directories that can be read by
9
system scripts ), Again, this is established in the general security
policy.
httpd_sys_script_rw_t, (files or 10
Modifications were made to suEXEC to transition
directories that can be read and the role of the process.
9

10. type transitions to process that had the same security context as
httpd_user_script_process_t. the Apache daemon. This process executed
∑ When the daemon executes a user a number of shell commands in an attempt
script (httpd_user_script_t) without to cause damage to the system. For instance,
using suEXEC, the process type the malicious process attempted to remove
t r a n s i t i o n s t o all of the files in the /etc directory, to install
httpd_user_script_process_t. and execute files in /bin, and to read various
∑ When a user executes a user script, files on the system.
the process type transitions to Modifying, deleting, installing, and
httpd_user_script_process_t. executing files was also attempted in the
The policy allows processes of type system web directory and in a user's web
httpd_sys_script_process_t (system script directory. The process could append to the
processes) and httpd_user_script_process_t web log files but could not remove data
to from these files. Other than the log files, the
∑ execute files of type bin_t (script process could not write to any files, and,
interpreters) and therefore, could not deface web pages. The
∑ execute files of type lib_t (libraries). malicious process was prevented from
The policy allows processes of type deleting or installing files. The process was
httpd_sys_script_process_t (system script also prevented from executing files that
processes) to were not scripts. The process could only
∑ read files of type read files it had read access to such as web
httpd_sys_script_r_t, pages, web configuration files, and web log
∑ read and write files of type files.
httpd_sys_script_rw_t, and We also created a malicious CGI script
to see what damage this could cause. The
∑ apend files of type
CGI script attempted similar actions to the
httpd_sys_script_a_t.
ones we executed from the malicious
The policy allows processes of type
process. We installed this script as both a
httpd_user_script_process_t (user script
system script and as a user script.
processes) to
When the Apache server executed the
∑ read files of type
system script, most actions were again
httpd_user_script_r_t,
denied. As expected, files in the web server
∑ read and write files of type directory that could be written to by system
httpd_user_script_rw_t, and scripts were deleted or modified.
∑ apend files of type Therefore, web pages that can be written to
httpd_user_script_a_t. by scripts could potentially be defaced.
Everything not explicitly allowed by the Therefore, web designers should be careful
policy is denied. when designing pages that allow scripts to
write to them.
Limited Damage, Same Functionality
When the Apache server executed the
To demonstrate that the policy limits the user script, most actions were again denied.
potential damage caused via the malicious As expected, files in the user directory that
use of the Apache web server, we performed could be written to by user scripts were
security testing. During security testing, we deleted or modified.
simulated a malicious user gaining control When the HTTP administrator executed
of the Apache server by creating a malicious the system script, the script was able to
10

11. modify files that could be written to by applications to take advantage of the
system scripts. Other actions were denied. security features provided by Security-
When a user executed the user script, the Enhanced Linux.
script was able to damage files that could be Because Security-Enhanced Linux
written to by user scripts. This included separates enforcement from policy, the
files that allowed discretionary write access system administrator can tailor the policy to
to that user but were not necessarily owned confine site-required applications, as was
by that user. Other actions were prevented. done with Apache. Tailoring the policy to
Our security testing demonstrates that if confine the applications results in a reduced
a malicious user takes control of the web level of risk when making these applications
server process or issues commands to the available.
web server via CGIs or SSIs, that user will Because of the flexibility of the
be able to cause only limited damage. Security-Enhanced Linux policy, the policy
Therefore, the policy limits damage, but is able to confine an application without
does it also limit functionality? reducing the application's functionality
To demonstrate that Apache expected by users.
functionality operated as expected, we
performed functionality testing.
During functionality testing, all
functionality that we expected to be allowed
by the policy was tested. For example,
testing verified that the Apache server was
started at boot time. The HTTP
administrator was allowed to stop and restart
the Apache server. The administrator was
also allowed to create and modify system
web pages and create scripts. Users were
also allowed to create web pages and scripts.
Via a network connection, we requested
both a system web page and a user web page
from the Apache server. The Apache server
read both web pages, executed the CGI
scripts that they called, and displayed the
web pages. Password protection via
.htaccess files worked as expected.
Summary
This work demonstrates how the Apache
web server can be confined to limit the
potential damage caused if vulnerabilities
associated with the Apache web server are
exploited.
In addition, we have also shown that
Security-Enhanced Linux can support
commonly used applications. Therefore,
users do not have to forgo their preferred
11

12. References [10] S. Smalley and T. Fraser. A Security
Policy Configuration for the Security-
[1] The National Security Agency, Security- Enhanced Linux. Technical Report, NAI
Enhanced Linux, Labs, February 2001.
http://www.nsa.gov/selinux
[2] P. Loscocco and S. Smalley. Integrating
Flexible Support for Security Policies into
the Linux Operating System. Technical
report, NSA and NAI Labs, February 2001.
[3] P. Loscocco and S. Smalley. Integrating
Flexible Support for Security Policies into
the Linux Operating System. In
Proceedings of the FREENIX Track: 2001
USENIX Annual Technical Conference
(FREENIX '01), June 2001.
[4 ] P. Loscocco and S. Smalley, Meeting
Critical Security Objectives with Security-
Enhanced Linux. In Proceedings of the 2001
Ottawa Linux Symposium, July 2001.
[5] The World Wide Web Security FAQ
http://www-
genome.wi.mit.edu/WWW/faqs/www-
security-faq.html#contents
[6] Computer Incident Advisory Capability
web site,
http://ciac.llnl.gov//ciac/documents/ciac2308
.html#4
[7]Apache suEXEC Support,
http://httpd.apache.org/docs/suexec.html
[8]SLAC's Script Security Wrapper,
http://www.slac.stanford.edu/slac/www/tool/
cgi-wrap/doc/
[9] sbox,
http://stein.cshl.org/WWW/software/sbox/
by Cold Spring Harbor Laboratory,
http://www.cshl.org.
12