ACC SHELL
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 19. Immunizing Programs</title><link rel="stylesheet" href="susebooks.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Documentation"><link rel="up" href="part.apparmor.html" title="Part IV. Confining Privileges with Novell AppArmor"><link rel="prev" href="cha.apparmor.start.html" title="Chapter 18. Getting Started"><link rel="next" href="cha.apparmor.profiles.html" title="Chapter 20. Profile Components and Syntax"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.security.html">Security Guide</a><span class="breadcrumbs-sep"> > </span><a href="part.apparmor.html">Confining Privileges with Novell AppArmor</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="Chapter 18. Getting Started" href="cha.apparmor.start.html"><span>◀</span></a> <a accesskey="n" title="Chapter 20. Profile Components and Syntax" href="cha.apparmor.profiles.html"><span>▶</span></a></strong></p></div></td></tr></table></div><div class="chapter" title="Chapter 19. Immunizing Programs"><div class="titlepage"><div><div><h2 class="title"><a name="cha.apparmor.concept"></a>Chapter 19. Immunizing Programs<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#cha.apparmor.concept">¶</a></span></h2></div></div></div><div class="toc"><p><b>Contents</b></p><dl><dt><span class="sect1"><a href="cha.apparmor.concept.html#sec.apparmor.concept.tools">19.1. Introducing the AppArmor Framework</a></span></dt><dt><span class="sect1"><a href="cha.apparmor.concept.html#sec.apparmor.concept.determine">19.2. Determining Programs to Immunize</a></span></dt><dt><span class="sect1"><a href="cha.apparmor.concept.html#sec.apparmor.concept.cron">19.3. Immunizing cron Jobs</a></span></dt><dt><span class="sect1"><a href="cha.apparmor.concept.html#sec.apparmor.concept.network">19.4. Immunizing Network Applications</a></span></dt></dl></div><p>
Effective hardening of a computer system requires minimizing the number of
programs that mediate privilege, then securing the programs as much as
possible. With Novell AppArmor, you only need to profile the programs that are
exposed to attack in your environment, which drastically reduces the
amount of work required to harden your computer. AppArmor profiles enforce
policies to make sure that programs do what they are supposed to do, but
nothing else.
</p><p>
Novell® AppArmor provides immunization technologies that protect applications from
the inherent vulnerabilities they possess. After installing Novell AppArmor, setting
up Novell AppArmor profiles, and rebooting the computer, your system becomes
immunized because it begins to enforce the Novell AppArmor security policies.
Protecting programs with Novell AppArmor is referred to as
<span class="emphasis"><em>immunizing</em></span>.
</p><p>
Administrators need only concern themselves with the applications that are
vulnerable to attacks, and generate profiles for these. Hardening a system
thus comes down to building and maintaining the AppArmor profile set and
monitoring any policy violations or exceptions logged by AppArmor's reporting
facility.
</p><p>
Users should not notice AppArmor at all. It runs <span class="quote">“<span class="quote">behind the
scenes</span>”</span> and does not require any user interaction. Performance is
not noticeably affected by AppArmor. If some activity of the application is
not covered by an AppArmor profile or if some activity of the application is
prevented by AppArmor, the administrator needs to adjust the profile of this
application to cover this kind of behavior.
</p><p>
Novell AppArmor sets up a collection of default application profiles to protect
standard Linux services. To protect other applications, use the Novell AppArmor
tools to create profiles for the applications that you want protected.
This chapter introduces the philosophy of immunizing programs. Proceed to
<a class="xref" href="cha.apparmor.profiles.html" title="Chapter 20. Profile Components and Syntax">Chapter 20, <i>Profile Components and Syntax</i></a>,
<a class="xref" href="cha.apparmor.yast.html" title="Chapter 22. Building and Managing Profiles with YaST">Chapter 22, <i>Building and Managing Profiles with YaST</i></a>, or
<a class="xref" href="cha.apparmor.commandline.html" title="Chapter 23. Building Profiles from the Command Line">Chapter 23, <i>Building Profiles from the Command Line</i></a> if you are ready to build and
manage Novell AppArmor profiles.
</p><p>
Novell AppArmor provides streamlined access control for network services by
specifying which files each program is allowed to read, write, and
execute, and which type of network it is allowed to access. This ensures
that each program does what it is supposed to do, and nothing else. Novell AppArmor
quarantines programs to protect the rest of the system from being damaged
by a compromised process.
</p><p>
Novell AppArmor is a host intrusion prevention or mandatory access control scheme.
Previously, access control schemes were centered around users because they
were built for large timeshare systems. Alternatively, modern network
servers largely do not permit users to log in, but instead provide a
variety of network services for users (such as Web, mail, file, and print
servers). Novell AppArmor controls the access given to network services and other
programs to prevent weaknesses from being exploited.
</p><div class="tip"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Tip: Background Information for Novell AppArmor"><tr class="head"><td width="32"><img alt="[Tip]" src="admon/tip.png"></td><th align="left">Background Information for Novell AppArmor</th></tr><tr><td colspan="2" align="left" valign="top"><p>
To get a more in-depth overview of AppArmor and the overall concept behind
it, refer to <a class="xref" href="cha.apparmor.intro.html#sec.apparmor.intro.background" title="17.1. Background Information on AppArmor Profiling">Section 17.1, “Background Information on AppArmor Profiling”</a>.
</p></td></tr></table></div><div class="sect1" title="19.1. Introducing the AppArmor Framework"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.concept.tools"></a>19.1. Introducing the AppArmor Framework<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.concept.tools">¶</a></span></h2></div></div></div><p>
This section provides a very basic understanding of what is happening
<span class="quote">“<span class="quote">behind the scenes</span>”</span> (and under the hood of the YaST
interface) when you run AppArmor.
</p><p>
An AppArmor profile is a plain text file containing path entries and access
permissions. See <a class="xref" href="cha.apparmor.profiles.html#sec.apparmor.profiles.parts" title="20.1. Breaking a Novell AppArmor Profile into Its Parts">Section 20.1, “Breaking a Novell AppArmor Profile into Its Parts”</a> for a
detailed reference profile. The directives contained in this text file
are then enforced by the AppArmor routines to quarantine the process or
program.
</p><p>
The following tools interact in the building and enforcement of AppArmor
profiles and policies:
</p><div class="variablelist"><dl><dt><span class="term"><span class="command"><strong>aa-unconfined</strong></span> / <span class="command"><strong>unconfined</strong></span>
</span></dt><dd><p>
<span class="command"><strong>aa-unconfined</strong></span> detects any application running on
your system that listens for network connections and is not protected
by an AppArmor profile. Refer to
<a class="xref" href="cha.apparmor.commandline.html#sec.apparmor.commandline.profiling.summary.unconfined" title="23.6.3.8. aa-unconfined—Identifying Unprotected Processes">Section 23.6.3.8, “aa-unconfined—Identifying Unprotected Processes”</a>
for detailed information about this tool.
</p></dd><dt><span class="term"><span class="command"><strong>aa-autodep</strong></span> / <span class="command"><strong>autodep</strong></span>
</span></dt><dd><p>
<span class="command"><strong>aa-autodep</strong></span> creates a basic framework of a profile
that needs to be fleshed out before it is put to use in production.
The resulting profile is loaded and put into complain mode, reporting
any behavior of the application that is not (yet) covered by AppArmor
rules. Refer to
<a class="xref" href="cha.apparmor.commandline.html#sec.apparmor.commandline.profiling.summary.autodep" title="23.6.3.1. aa-autodep—Creating Approximate Profiles">Section 23.6.3.1, “aa-autodep—Creating Approximate Profiles”</a>
for detailed information about this tool.
</p></dd><dt><span class="term"><span class="command"><strong>aa-genprof</strong></span> / <span class="command"><strong>genprof</strong></span>
</span></dt><dd><p>
<span class="command"><strong>aa-genprof</strong></span> generates a basic profile and asks you
to refine this profile by executing the application and generating log
events that need to be taken care of by AppArmor policies. You are guided
through a series of questions to deal with the log events that have
been triggered during the application's execution. After the profile
has been generated, it is loaded and put into enforce mode. Refer to
<a class="xref" href="cha.apparmor.commandline.html#sec.apparmor.commandline.profiling.summary.genprof" title="23.6.3.4. aa-genprof—Generating Profiles">Section 23.6.3.4, “aa-genprof—Generating Profiles”</a>
for detailed information about this tool.
</p></dd><dt><span class="term"><span class="command"><strong>aa-logprof</strong></span> / <span class="command"><strong>logprof</strong></span>
</span></dt><dd><p>
<span class="command"><strong>aa-logprof</strong></span> interactively scans and reviews the log
entries generated by an application that is confined by an AppArmor
profile in complain mode. It assists you in generating new entries in
the profile concerned. Refer to
<a class="xref" href="cha.apparmor.commandline.html#sec.apparmor.commandline.profiling.summary.logprof" title="23.6.3.5. aa-logprof—Scanning the System Log">Section 23.6.3.5, “aa-logprof—Scanning the System Log”</a>
for detailed information about this tool.
</p></dd><dt><span class="term"><span class="command"><strong>aa-complain</strong></span> / <span class="command"><strong>complain</strong></span>
</span></dt><dd><p>
<span class="command"><strong>aa-complain</strong></span> toggles the mode of an AppArmor profile
from enforce to complain. Exceptions to rules set in a profile are
logged, but the profile is not enforced. Refer to
<a class="xref" href="cha.apparmor.commandline.html#sec.apparmor.commandline.profiling.summary.complain" title="23.6.3.2. aa-complain—Entering Complain or Learning Mode">Section 23.6.3.2, “aa-complain—Entering Complain or Learning Mode”</a>
for detailed information about this tool.
</p></dd><dt><span class="term"><span class="command"><strong>aa-enforce</strong></span> / <span class="command"><strong>enforce</strong></span>
</span></dt><dd><p>
<span class="command"><strong>aa-enforce</strong></span> toggles the mode of an AppArmor profile from
complain to enforce. Exceptions to rules set in a profile are logged,
but not permitted—the profile is enforced. Refer to
<a class="xref" href="cha.apparmor.commandline.html#sec.apparmor.commandline.profiling.summary.enforce" title="23.6.3.3. aa-enforce—Entering Enforce Mode">Section 23.6.3.3, “aa-enforce—Entering Enforce Mode”</a>
for detailed information about this tool.
</p></dd></dl></div><p>
Once a profile has been built and is loaded, there are two ways in which
it can get processed:
</p><div class="variablelist"><dl><dt><span class="term"><span class="command"><strong>aa-complain</strong></span> / <span class="command"><strong>complain</strong></span>
</span></dt><dd><p>
In complain mode, violations of AppArmor profile rules, such as the
profiled program accessing files not permitted by the profile, are
detected. The violations are permitted, but also logged. To improve
the profile, turn complain mode on, run the program through a suite of
tests to generate log events that characterize the program's access
needs, then postprocess the log with the AppArmor tools (YaST or
aa-logprof) to transform log events into improved profiles.
</p></dd><dt><span class="term"><span class="command"><strong>aa-enforce</strong></span> / <span class="command"><strong>enforce</strong></span>
</span></dt><dd><p>
In enforce mode, violations of AppArmor profile rules, such as the
profiled program accessing files not permitted by the profile, are
detected. The violations are logged and not permitted. The default is
for enforce mode to be enabled. To log the violations only, but still
permit them, use complain mode. Enforce toggles with complain mode.
</p></dd></dl></div></div><div class="sect1" title="19.2. Determining Programs to Immunize"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.concept.determine"></a>19.2. Determining Programs to Immunize<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.concept.determine">¶</a></span></h2></div></div></div><p>
Now that you have familiarized yourself with AppArmor, start selecting the
applications for which to build profiles. Programs that need profiling
are those that mediate privilege. The following programs have access to
resources that the person using the program does not have, so they grant
the privilege to the user when used:
</p><div class="variablelist"><dl><dt><span class="term">cron Jobs</span></dt><dd><p>
Programs that are run periodically by cron. Such programs read input
from a variety of sources and can run with special privileges,
sometimes with as much as <code class="systemitem">root</code> privilege. For example, cron can
run <span class="command"><strong>/usr/sbin/logrotate</strong></span> daily to rotate, compress,
or even mail system logs. For instructions for finding these types of
programs, refer to
<a class="xref" href="cha.apparmor.concept.html#sec.apparmor.concept.cron" title="19.3. Immunizing cron Jobs">Section 19.3, “Immunizing cron Jobs”</a>.
</p></dd><dt><span class="term">Web Applications</span></dt><dd><p>
Programs that can be invoked through a Web browser, including CGI Perl
scripts, PHP pages, and more complex Web applications. For
instructions for finding these types of programs, refer to
<a class="xref" href="cha.apparmor.concept.html#sec.apparmor.concept.network.web" title="19.4.1. Immunizing Web Applications">Section 19.4.1, “Immunizing Web Applications”</a>.
</p></dd><dt><span class="term">Network Agents</span></dt><dd><p>
Programs (servers and clients) that have open network ports. User
clients, such as mail clients and Web browsers mediate privilege.
These programs run with the privilege to write to the user's home
directory and they process input from potentially hostile remote
sources, such as hostile Web sites and e-mailed malicious code. For
instructions for finding these types of programs, refer to
<a class="xref" href="cha.apparmor.concept.html#sec.apparmor.concept.network.agents" title="19.4.2. Immunizing Network Agents">Section 19.4.2, “Immunizing Network Agents”</a>.
</p></dd></dl></div><p>
Conversely, unprivileged programs do not need to be profiled. For
instance, a shell script might invoke the <span class="command"><strong>cp</strong></span> program
to copy a file. Because <span class="command"><strong>cp</strong></span> does not have its own
profile, it inherits the profile of the parent shell script, so can copy
any files that the parent shell script's profile can read and write.
</p></div><div class="sect1" title="19.3. Immunizing cron Jobs"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.concept.cron"></a>19.3. Immunizing cron Jobs<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.concept.cron">¶</a></span></h2></div></div></div><p>
To find programs that are run by cron, inspect your local cron
configuration. Unfortunately, cron configuration is rather complex, so
there are numerous files to inspect. Periodic cron jobs are run from
these files:
</p><pre class="screen">/etc/crontab
/etc/cron.d/*
/etc/cron.daily/*
/etc/cron.hourly/*
/etc/cron.monthly/*
/etc/cron.weekly/*
</pre><p>
For <code class="systemitem">root</code>'s cron jobs, edit the tasks with <span class="command"><strong>crontab
-e</strong></span> and list <code class="systemitem">root</code>'s cron tasks with <span class="command"><strong>crontab
-l</strong></span>. You must be <code class="systemitem">root</code> for these to work.
</p><p>
Once you find these programs, you can use the <span class="guimenu">Add Profile
Wizard</span> to create profiles for them. Refer to
<a class="xref" href="cha.apparmor.yast.html#sec.apparmor.yast.wizard" title="22.1. Adding a Profile Using the Wizard">Section 22.1, “Adding a Profile Using the Wizard”</a>.
</p></div><div class="sect1" title="19.4. Immunizing Network Applications"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.concept.network"></a>19.4. Immunizing Network Applications<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.concept.network">¶</a></span></h2></div></div></div><p>
An automated method for finding network server daemons that should be
profiled is to use the <span class="command"><strong>aa-unconfined</strong></span> tool. You can
also simply view a report of this information in the YaST module (refer
to
<a class="xref" href="cha.apparmor.managing.html#sec.apparmor.managing.config_reports.view.audit" title="26.3.1.1. Application Audit Report">Section 26.3.1.1, “Application Audit Report”</a>
for instructions).
</p><p>
The <span class="command"><strong>aa-unconfined</strong></span> tool uses the command
<span class="command"><strong>netstat -nlp</strong></span> to inspect your open ports from inside
your computer, detect the programs associated with those ports, and
inspect the set of Novell AppArmor profiles that you have loaded.
<span class="command"><strong>aa-unconfined</strong></span> then reports these programs along with
the Novell AppArmor profile associated with each program, or reports
<span class="quote">“<span class="quote">none</span>”</span> (if the program is not confined).
</p><div class="note"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Note"><tr class="head"><td width="32"><img alt="[Note]" src="admon/note.png"></td><th align="left"></th></tr><tr><td colspan="2" align="left" valign="top"><p>
If you create a new profile, you must restart the program that has been
profiled to have it be effectively confined by AppArmor.
</p></td></tr></table></div><p>
Below is a sample <span class="command"><strong>aa-unconfined</strong></span> output:
</p><pre class="screen">
2325 /sbin/portmap not confined
3702<a name="co.apparmor.concept.network.id"></a><img src="callouts/1.png" alt="1" border="0"> /usr/sbin/sshd<a name="co.apparmor.concept.network.string"></a><img src="callouts/2.png" alt="2" border="0"> confined
by '/usr/sbin/sshd<a name="co.apparmor.concept.network.confine"></a><img src="callouts/3.png" alt="3" border="0"> (enforce)'
4040 /usr/sbin/ntpd confined by '/usr/sbin/ntpd (enforce)'
4373 /usr/lib/postfix/master confined by '/usr/lib/postfix/master (enforce)'
4505 /usr/sbin/httpd2-prefork confined by '/usr/sbin/httpd2-prefork (enforce)'
5274 /sbin/dhcpcd not confined
5592 /usr/bin/ssh not confined
7146 /usr/sbin/cupsd confined by '/usr/sbin/cupsd (complain)'
</pre><div class="calloutlist"><table border="0" summary="Callout list"><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.concept.network.id"><img src="callouts/1.png" alt="1" border="0"></a> </p></td><td valign="top" align="left"><p>
The first portion is a number. This number is the process ID number
(PID) of the listening program.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.concept.network.string"><img src="callouts/2.png" alt="2" border="0"></a> </p></td><td valign="top" align="left"><p>
The second portion is a string that represents the absolute path of the
listening program
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.concept.network.confine"><img src="callouts/3.png" alt="3" border="0"></a> </p></td><td valign="top" align="left"><p>
The final portion indicates the profile confining the program, if any.
</p></td></tr></table></div><div class="note"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Note"><tr class="head"><td width="32"><img alt="[Note]" src="admon/note.png"></td><th align="left"></th></tr><tr><td colspan="2" align="left" valign="top"><p>
<span class="command"><strong>aa-unconfined</strong></span> requires <code class="systemitem">root</code> privileges and
should not be run from a shell that is confined by an AppArmor profile.
</p></td></tr></table></div><p>
<span class="command"><strong>aa-unconfined</strong></span> does not distinguish between one network
interface and another, so it reports all unconfined processes, even those
that might be listening to an internal LAN interface.
</p><p>
Finding user network client applications is dependent on your user
preferences. The <span class="command"><strong>aa-unconfined</strong></span> tool detects and
reports network ports opened by client applications, but only those
client applications that are running at the time the
<span class="command"><strong>aa-unconfined</strong></span> analysis is performed. This is a problem
because network services tend to be running all the time, while network
client applications tend only to be running when the user is interested
in them.
</p><p>
Applying Novell AppArmor profiles to user network client applications is also
dependent on user preferences. Therefore, we leave the profiling of user
network client applications as an exercise for the user.
</p><p>
To aggressively confine desktop applications, the
<span class="command"><strong>aa-unconfined</strong></span> command supports a
<code class="option">paranoid</code> option, which reports all processes running and
the corresponding AppArmor profiles that might or might not be associated
with each process. The user can then decide whether each of these
programs needs an AppArmor profile.
</p><p>
If you have new or modified profiles, you can submit them to the
<a class="ulink" href="mailto:apparmor-general@forge.novell.com" target="_top">apparmor-general@forge.novell.com</a>
mailing list along with a use case for the application behavior that you
exercised. The AppArmor team reviews and may submit the work into
<span>openSUSE</span>.
We cannot guarantee that every profile will be included, but we make a
sincere effort to include as much as possible so that end users can
contribute to the security profiles that ship in
<span>openSUSE</span>.
</p><p>
Alternatively, use the AppArmor profile repository to make your profiles
available to other users and to download profiles created by other AppArmor
users and the AppArmor developers. Refer to
<a class="xref" href="cha.apparmor.repos.html" title="Chapter 21. AppArmor Profile Repositories">Chapter 21, <i>AppArmor Profile Repositories</i></a> for more information on how to
use the AppArmor profile repository.
</p><div class="sect2" title="19.4.1. Immunizing Web Applications"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.concept.network.web"></a>19.4.1. Immunizing Web Applications<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.concept.network.web">¶</a></span></h3></div></div></div><p>
To find Web applications, investigate your Web server configuration. The
Apache Web server is highly configurable and Web applications can be
stored in many directories, depending on your local configuration.
<span>openSUSE</span>,
by default, stores Web applications in
<code class="filename">/srv/www/cgi-bin/</code>. To the maximum extent possible,
each Web application should have an Novell AppArmor profile.
</p><p>
Once you find these programs, you can use the AppArmor <span class="guimenu">Add Profile
Wizard</span> to create profiles for them. Refer to
<a class="xref" href="cha.apparmor.yast.html#sec.apparmor.yast.wizard" title="22.1. Adding a Profile Using the Wizard">Section 22.1, “Adding a Profile Using the Wizard”</a>.
</p><p>
Because CGI programs are executed by the Apache Web server, the profile
for Apache itself, <code class="filename">usr.sbin.httpd2-prefork</code> for
Apache2 on
<span>openSUSE</span>,
must be modified to add execute permissions to each of these programs.
For instance, adding the line
<code class="literal">/srv/www/cgi-bin/my_hit_counter.pl rpx</code> grants Apache
permission to execute the Perl script
<code class="filename">my_hit_counter.pl</code> and requires that there be a
dedicated profile for <code class="filename">my_hit_counter.pl</code>. If
<code class="filename">my_hit_counter.pl</code> does not have a dedicated profile
associated with it, the rule should say
<code class="literal">/srv/www/cgi-bin/my_hit_counter.pl rix</code> to cause
<code class="filename">my_hit_counter.pl</code> to inherit the
<code class="filename">usr.sbin.httpd2-prefork</code> profile.
</p><p>
Some users might find it inconvenient to specify execute permission for
every CGI script that Apache might invoke. Instead, the administrator
can grant controlled access to collections of CGI scripts. For instance,
adding the line <code class="literal">/srv/www/cgi-bin/*.{pl,py,pyc} rix</code>
allows Apache to execute all files in
<code class="literal">/srv/www/cgi-bin/</code> ending in <code class="filename">.pl</code>
(Perl scripts) and <code class="filename">.py</code> or <code class="filename">.pyc</code>
(Python scripts). As above, the <code class="literal">ix</code> part of the rule
causes Python scripts to inherit the Apache profile, which is
appropriate if you do not want to write individual profiles for each
Python script.
</p><div class="note"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Note"><tr class="head"><td width="32"><img alt="[Note]" src="admon/note.png"></td><th align="left"></th></tr><tr><td colspan="2" align="left" valign="top"><p>
If you want the subprocess confinement module
(<code class="filename">apache2-mod-apparmor</code>) functionality when Web
applications handle Apache modules (<code class="filename">mod_perl</code> and
<code class="filename">mod_php</code>), use the ChangeHat features when you add
a profile in YaST or at the command line. To take advantage of the
subprocess confinement, refer to
<a class="xref" href="cha.apparmor.hat.html#sec.apparmor.hat.apache" title="24.1. Apache ChangeHat">Section 24.1, “Apache ChangeHat”</a>.
</p></td></tr></table></div><p>
Profiling Web applications that use <code class="filename">mod_perl</code> and
<code class="filename">mod_php</code> requires slightly different handling. In
this case, the <span class="quote">“<span class="quote">program</span>”</span> is a script interpreted directly
by the module within the Apache process, so no exec happens. Instead,
the Novell AppArmor version of Apache calls <span class="command"><strong>change_hat()</strong></span> using
a subprofile (a <span class="quote">“<span class="quote">hat</span>”</span>) corresponding to the name of the URI
requested.
</p><div class="note"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Note"><tr class="head"><td width="32"><img alt="[Note]" src="admon/note.png"></td><th align="left"></th></tr><tr><td colspan="2" align="left" valign="top"><p>
The name presented for the script to execute might not be the URI,
depending on how Apache has been configured for where to look for
module scripts. If you have configured your Apache to place scripts in
a different place, the different names appear in log file when Novell AppArmor
complains about access violations. See
<a class="xref" href="cha.apparmor.managing.html" title="Chapter 26. Managing Profiled Applications">Chapter 26, <i>Managing Profiled Applications</i></a>.
</p></td></tr></table></div><p>
For <code class="filename">mod_perl</code> and <code class="filename">mod_php</code>
scripts, this is the name of the Perl script or the PHP page requested.
For example, adding this subprofile allows the
<code class="filename">localtime.php</code> page to execute and access the local
system time:
</p><pre class="screen">/usr/bin/httpd2-prefork {
# ...
^/cgi-bin/localtime.php {
/etc/localtime r,
/srv/www/cgi-bin/localtime.php r,
/usr/lib/locale/** r,
}
}
</pre><p>
If no subprofile has been defined, the Novell AppArmor version of Apache applies
the <code class="systemitem">DEFAULT_URI</code> hat. This subprofile is
basically sufficient to display an HTML Web page. The
<code class="systemitem">DEFAULT_URI</code> hat that Novell AppArmor provides by default
is the following:
</p><pre class="screen">^DEFAULT_URI {
/usr/sbin/suexec2 mixr,
/var/log/apache2/** rwl,
@{HOME}/public_html r,
@{HOME}/public_html/** r,
/srv/www/htdocs r,
/srv/www/htdocs/** r,
/srv/www/icons/*.{gif,jpg,png} r,
/srv/www/vhosts r,
/srv/www/vhosts/** r,
/usr/share/apache2/** r,
/var/lib/php/sess_* rwl }
</pre><p>
To use a single Novell AppArmor profile for all Web pages and CGI scripts served
by Apache, a good approach is to edit the
<code class="systemitem">DEFAULT_URI</code> subprofile.
</p></div><div class="sect2" title="19.4.2. Immunizing Network Agents"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.concept.network.agents"></a>19.4.2. Immunizing Network Agents<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.concept.network.agents">¶</a></span></h3></div></div></div><p>
To find network server daemons and network clients (such as fetchmail,
Firefox, Amarok or Banshee) that need to be profiled, you should
inspect the open ports on your machine, consider the programs that are
answering on those ports, and provide profiles for as many of those
programs as possible. If you provide profiles for all programs with open
network ports, an attacker cannot get to the file system on your machine
without passing through a Novell AppArmor profile policy.
</p><p>
Scan your server for open network ports manually from outside the
machine using a scanner (such as nmap), or from inside the machine using
the <span class="command"><strong>netstat --inet -n -p</strong></span> command. Then, inspect the
machine to determine which programs are answering on the discovered open
ports.
</p><div class="tip"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Tip"><tr class="head"><td width="32"><img alt="[Tip]" src="admon/tip.png"></td><th align="left"></th></tr><tr><td colspan="2" align="left" valign="top"><p>
Refer to the man page of the <span class="command"><strong>netstat</strong></span> command for a
detailed reference of all possible options.
</p></td></tr></table></div></div></div></div><div class="navfooter"><table width="100%" summary="Navigation footer" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.security.html">Security Guide</a><span class="breadcrumbs-sep"> > </span><a href="part.apparmor.html">Confining Privileges with Novell AppArmor</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="Chapter 18. Getting Started" href="cha.apparmor.start.html"><span>◀</span></a> <a accesskey="n" title="Chapter 20. Profile Components and Syntax" href="cha.apparmor.profiles.html"><span>▶</span></a></strong></p></div></td></tr></table></div></body></html>
ACC SHELL 2018