• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Confining the Apache Web Server with Security-Enhanced Linux
 

Confining the Apache Web Server with Security-Enhanced Linux

on

  • 887 views

 

Statistics

Views

Total Views
887
Views on SlideShare
887
Embed Views
0

Actions

Likes
0
Downloads
7
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Confining the Apache Web Server with Security-Enhanced Linux Confining the Apache Web Server with Security-Enhanced Linux Document Transcript

    • 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
    • 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
    • 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
    • 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. 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. - display web pages back to the To support this high-level policy, we 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
    • their assigned types and roles are listed in table 1. 6
    • 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
    • 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
    • ∑ 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
    • 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
    • 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
    • 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