ACC SHELL
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 20. Profile Components and Syntax</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.concept.html" title="Chapter 19. Immunizing Programs"><link rel="next" href="cha.apparmor.repos.html" title="Chapter 21. AppArmor Profile Repositories"></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 19. Immunizing Programs" href="cha.apparmor.concept.html"><span>◀</span></a> <a accesskey="n" title="Chapter 21. AppArmor Profile Repositories" href="cha.apparmor.repos.html"><span>▶</span></a></strong></p></div></td></tr></table></div><div class="chapter" title="Chapter 20. Profile Components and Syntax"><div class="titlepage"><div><div><h2 class="title"><a name="cha.apparmor.profiles"></a>Chapter 20. Profile Components and Syntax<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#cha.apparmor.profiles">¶</a></span></h2></div></div></div><div class="toc"><p><b>Contents</b></p><dl><dt><span class="sect1"><a href="cha.apparmor.profiles.html#sec.apparmor.profiles.parts">20.1. Breaking a Novell AppArmor Profile into Its Parts</a></span></dt><dt><span class="sect1"><a href="cha.apparmor.profiles.html#sec.apparmor.profiles.types">20.2. Profile Types</a></span></dt><dt><span class="sect1"><a href="cha.apparmor.profiles.html#sec.apparmor.profiles.includes">20.3. <code class="literal">#include</code> Statements</a></span></dt><dt><span class="sect1"><a href="cha.apparmor.profiles.html#sec.apparmor.profiles.capabilities">20.4. Capability Entries (POSIX.1e)</a></span></dt><dt><span class="sect1"><a href="cha.apparmor.profiles.html#sec.apparmor.profiles.nac">20.5. Network Access Control</a></span></dt><dt><span class="sect1"><a href="cha.apparmor.profiles.html#sec.apparmor.profiles.glob">20.6. Paths and Globbing</a></span></dt><dt><span class="sect1"><a href="cha.apparmor.profiles.html#sec.apparmor.profiles.perm">20.7. File Permission Access Modes</a></span></dt><dt><span class="sect1"><a href="cha.apparmor.profiles.html#sec.apparmor.profiles.exec">20.8. Execute Modes</a></span></dt><dt><span class="sect1"><a href="cha.apparmor.profiles.html#sec.apparmor.profiles.rlimit">20.9. Resource Limit Control</a></span></dt><dt><span class="sect1"><a href="cha.apparmor.profiles.html#sec.apparmor.profiles.audit">20.10. Auditing Rules</a></span></dt><dt><span class="sect1"><a href="cha.apparmor.profiles.html#sec.apparmor.profiles.set_capabilities">20.11. Setting Capabilities per Profile</a></span></dt></dl></div><p>
Building AppArmor profiles to confine an application is very straightforward
and intuitive. AppArmor ships with several tools that assist in profile
creation. It does not require you to do any programming or script
handling. The only task that is required of the administrator is to
determine a policy of strictest access and execute permissions for each
application that needs to be hardened.
</p><p>
Updates or modifications to the application profiles are only required if
the software configuration or the desired range of activities changes.
AppArmor offers intuitive tools to handle profile updates and modifications.
</p><p>
You are ready to build Novell AppArmor profiles after you select the programs to
profile. To do so, it is important to understand the components and syntax
of profiles. AppArmor profiles contain several building blocks that help build
simple and reusable profile code:
</p><div class="variablelist"><dl><dt><span class="term"><code class="literal">#include</code> Files</span></dt><dd><p>
<code class="literal">#include</code> statements are used to pull in parts of
other AppArmor profiles to simplify the structure of new profiles.
</p></dd><dt><span class="term">Abstractions</span></dt><dd><p>
Abstractions are <code class="literal">#include</code> statements grouped by
common application tasks.
</p></dd><dt><span class="term">Program Chunks</span></dt><dd><p>
Program chunks are <code class="literal">#include</code> statements that contain
chunks of profiles that are specific to program suites.
</p></dd><dt><span class="term">Capability Entries</span></dt><dd><p>
Capability entries are profile entries for any of the POSIX.1e Linux
capabilities allowing a fine-grained control over what a confined
process is allowed to do through system calls that require privileges.
</p></dd><dt><span class="term">Network Access Control Entries</span></dt><dd><p>
Network Access Control Entries mediate network access based on the
address type and family.
</p></dd><dt><span class="term">Local Variable Definitions</span></dt><dd><p>
Local variables define shortcuts for paths.
</p></dd><dt><span class="term">File Access Control Entries</span></dt><dd><p>
File Access Control Entries specify the set of files an application can
access.
</p></dd><dt><span class="term">rlimit Entries</span></dt><dd><p>
rlimit entries set and control an application's resource limits.
</p></dd></dl></div><p>
For help determining the programs to profile, refer to
<a class="xref" href="cha.apparmor.concept.html#sec.apparmor.concept.determine" title="19.2. Determining Programs to Immunize">Section 19.2, “Determining Programs to Immunize”</a>.
To start building AppArmor profiles with YaST, proceed to
<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>. To build profiles using the AppArmor
command line interface, proceed to
<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>.
</p><div class="sect1" title="20.1. Breaking a Novell AppArmor Profile into Its Parts"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.profiles.parts"></a>20.1. Breaking a Novell AppArmor Profile into Its Parts<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.parts">¶</a></span></h2></div></div></div><p>
The easiest way of explaining what a profile consists of and how to
create one is to show the details of a sample profile, in this case for a
hypothetical application called <span class="command"><strong>/usr/bin/foo</strong></span>:
</p><pre class="screen">#include <tunables/global><a name="co.apparmor.profiles.vardef"></a><img src="callouts/1.png" alt="1" border="0">
# a comment naming the application to confine
/usr/bin/foo<a name="co.apparmor.profiles.path"></a><img src="callouts/2.png" alt="2" border="0">
{<a name="co.apparmor.profiles.brack"></a><img src="callouts/3.png" alt="3" border="0">
#include <abstractions/base><a name="co.apparmor.profiles.incl"></a><img src="callouts/4.png" alt="4" border="0">
capability setgid<a name="co.apparmor.profiles.capent"></a><img src="callouts/5.png" alt="5" border="0">,
network inet tcp<a name="co.apparmor.profiles.netd"></a><img src="callouts/6.png" alt="6" border="0">,
link /etc/sysconfig/foo -> /etc/foo.conf,<a name="co.apparmor.profiles.lp"></a><img src="callouts/7.png" alt="7" border="0">
/bin/mount ux,
/dev/{,u}<a name="co.apparmor.profiles.ext"></a><img src="callouts/8.png" alt="8" border="0">random r,
/etc/ld.so.cache r,
/etc/foo/* r,
/lib/ld-*.so* mr,
/lib/lib*.so* mr,
/proc/[0-9]** r,
/usr/lib/** mr,
/tmp/<a name="co.apparmor.profiles.pathent"></a><img src="callouts/9.png" alt="9" border="0"> r,
/tmp/foo.pid wr,
/tmp/foo.* lrw,
/@{HOME}<a name="co.apparmor.profiles.variable"></a><img src="callouts/10.png" alt="10" border="0">/.foo_file rw,
/@{HOME}/.foo_lock kw,
owner<a name="co.apparmor.profiles.owner"></a><img src="callouts/11.png" alt="11" border="0"> /shared/foo/** rw,
/usr/bin/foobar cx,<a name="co.apparmor.profiles.cx"></a><img src="callouts/12.png" alt="12" border="0">
/bin/** px -> bin_generic,<a name="co.apparmor.profiles.named"></a><img src="callouts/13.png" alt="13" border="0">
# a comment about foo's local (children)profile for /usr/bin/foobar.
profile /usr/bin/foobar<a name="co.apparmor.profiles.local"></a><img src="callouts/14.png" alt="14" border="0"> {
/bin/bash rmix,
/bin/cat rmix,
/bin/more rmix,
/var/log/foobar* rwl,
/etc/foobar r,
}
# foo's hat, bar.
^bar<a name="co.apparmor.profiles.hat"></a><img src="callouts/15.png" alt="15" border="0"> {
/lib/ld-*.so* mr,
/usr/bin/bar px,
/var/spool/* rwl,
}
}
</pre><div class="calloutlist"><table border="0" summary="Callout list"><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.vardef"><img src="callouts/1.png" alt="1" border="0"></a> </p></td><td valign="top" align="left"><p>
This loads a file containing variable definitions.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.path"><img src="callouts/2.png" alt="2" border="0"></a> </p></td><td valign="top" align="left"><p>
The normalized path to the program that is confined.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.brack"><img src="callouts/3.png" alt="3" border="0"></a> </p></td><td valign="top" align="left"><p>
The curly braces (<code class="literal">{}</code>) serve as a container for
include statements, subprofiles, path entries, capability entries, and
network entries.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.incl"><img src="callouts/4.png" alt="4" border="0"></a> </p></td><td valign="top" align="left"><p>
This directive pulls in components of AppArmor profiles to simplify
profiles.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.capent"><img src="callouts/5.png" alt="5" border="0"></a> </p></td><td valign="top" align="left"><p>
Capability entry statements enable each of the 29 POSIX.1e draft
capabilities.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.netd"><img src="callouts/6.png" alt="6" border="0"></a> </p></td><td valign="top" align="left"><p>
A directive determining the kind of network access allowed to the
application. For details, refer to
<a class="xref" href="cha.apparmor.profiles.html#sec.apparmor.profiles.nac" title="20.5. Network Access Control">Section 20.5, “Network Access Control”</a>.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.lp"><img src="callouts/7.png" alt="7" border="0"></a> </p></td><td valign="top" align="left"><p>
A link pair rule specifying the source and the target of a link. See
<a class="xref" href="cha.apparmor.profiles.html#sec.apparmor.profiles.perm.link_pair" title="20.7.6. Link Pair">Section 20.7.6, “Link Pair”</a> for more
information.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.ext"><img src="callouts/8.png" alt="8" border="0"></a> </p></td><td valign="top" align="left"><p>
The curly braces (<code class="literal">{}</code>) make this rule apply to the
path both with and without the content enclosed by the braces.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.pathent"><img src="callouts/9.png" alt="9" border="0"></a> </p></td><td valign="top" align="left"><p>
A path entry specifying what areas of the file system the program can
access. The first part of a path entry specifies the absolute path of a
file (including regular expression globbing) and the second part
indicates permissible access modes (for example <code class="literal">r</code>
for read, <code class="literal">w</code> for write, and <code class="literal">x</code> for
execute). A whitespace of any kind (spaces or tabs) can precede
pathnames or separate the pathname from the access modes. Spaces
between the access mode and the trailing comma are optional. Find a
comprehensive overview of the available access modes in
<a class="xref" href="cha.apparmor.profiles.html#sec.apparmor.profiles.perm" title="20.7. File Permission Access Modes">Section 20.7, “File Permission Access Modes”</a>.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.variable"><img src="callouts/10.png" alt="10" border="0"></a> </p></td><td valign="top" align="left"><p>
This variable expands to a value that can be changed without changing
the entire profile.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.owner"><img src="callouts/11.png" alt="11" border="0"></a> </p></td><td valign="top" align="left"><p>
An owner conditional rule, granting read and write permission on files
owned by the user. Refer to
<a class="xref" href="cha.apparmor.profiles.html#sec.apparmor.profiles.perm.owner" title="20.7.7. Owner Conditional Rules">Section 20.7.7, “Owner Conditional Rules”</a> for more
information.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.cx"><img src="callouts/12.png" alt="12" border="0"></a> </p></td><td valign="top" align="left"><p>
This entry defines a transition to the local profile
<code class="literal">/usr/bin/foobar</code>. Find a comprehensive overview of
the available execute modes in
<a class="xref" href="cha.apparmor.profiles.html#sec.apparmor.profiles.exec" title="20.8. Execute Modes">Section 20.8, “Execute Modes”</a>.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.named"><img src="callouts/13.png" alt="13" border="0"></a> </p></td><td valign="top" align="left"><p>
A named profile transition to the profile bin_generic located in the
global scope. See
<a class="xref" href="cha.apparmor.profiles.html#sec.apparmor.profiles.exec.named" title="20.8.7. Named Profile Transitions">Section 20.8.7, “Named Profile Transitions”</a> for details.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.local"><img src="callouts/14.png" alt="14" border="0"></a> </p></td><td valign="top" align="left"><p>
The local profile <code class="literal">/usr/bin/foobar</code> is defined in this
section.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.hat"><img src="callouts/15.png" alt="15" border="0"></a> </p></td><td valign="top" align="left"><p>
This section references a <span class="quote">“<span class="quote">hat</span>”</span> subprofile of the
application. For more details on AppArmor's ChangeHat feature, refer to
<a class="xref" href="cha.apparmor.hat.html" title="Chapter 24. Profiling Your Web Applications Using ChangeHat">Chapter 24, <i>Profiling Your Web Applications Using ChangeHat</i></a>.
</p></td></tr></table></div><p>
When a profile is created for a program, the program can access only the
files, modes, and POSIX capabilities specified in the profile. These
restrictions are in addition to the native Linux access controls.
</p><p title="Example:"><b>Example: </b>
To gain the capability <code class="systemitem">CAP_CHOWN</code>, the program
must have both access to <code class="systemitem">CAP_CHOWN</code> under
conventional Linux access controls (typically, be a <code class="systemitem">root</code>-owned
process) and have the capability <code class="systemitem">chown</code> in its
profile. Similarly, to be able to write to the file
<code class="filename">/foo/bar</code> the program must have both the correct
user ID and mode bits set in the files attributes (see the
<code class="systemitem">chmod</code> and <code class="systemitem">chown</code> man
pages) and have <code class="literal">/foo/bar w</code> in its profile.
</p><p>
Attempts to violate Novell AppArmor rules are recorded in
<code class="filename">/var/log/audit/audit.log</code> if the
<code class="systemitem">audit</code> package is installed
or otherwise in <code class="filename">/var/log/messages</code>. In many cases,
Novell AppArmor rules prevent an attack from working because necessary files are
not accessible and, in all cases, Novell AppArmor confinement restricts the damage
that the attacker can do to the set of files permitted by Novell AppArmor.
</p></div><div class="sect1" title="20.2. Profile Types"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.profiles.types"></a>20.2. Profile Types<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.types">¶</a></span></h2></div></div></div><p>
AppArmor knows four different types of profiles: standard profiles,
unattached profiles, local profiles and hats. Standard and unattached
profiles are stand-alone profiles, each stored in a file under
<code class="filename">/etc/apparmor.d/</code>. Local profiles and hats are
children profiles embedded inside of a parent profile used to provide
tighter or alternate confinement for a subtask of an application.
</p><div class="sect2" title="20.2.1. Standard Profiles"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.types.attached"></a>20.2.1. Standard Profiles<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.types.attached">¶</a></span></h3></div></div></div><p>
The default AppArmor profile is attached to a program by its name, so a
profile name must match the path to the application it is to confine.
</p><pre class="screen">/usr/bin/foo {
...
}
</pre><p>
This profile will be automatically used whenever an unconfined process
executes <code class="filename">/usr/bin/foo</code>.
</p></div><div class="sect2" title="20.2.2. Unattached Profiles"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.types.unattached"></a>20.2.2. Unattached Profiles<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.types.unattached">¶</a></span></h3></div></div></div><p>
Unattached profiles do not reside in the file system namespace and
therefore are not automatically attached to an application. The name of
an unattached profile is preceded by the keyword
<code class="literal">profile</code>. You can freely choose a profile name, except
for the following limitations: the name must not begin with a
<code class="literal">:</code> or <code class="literal">.</code> character. If it contains a
whitespace, it must be quoted. If the name begins with a
<code class="literal">/</code>, the profile is considered to be a standard
profile, so the following two profiles are identical:
</p><pre class="screen">profile /usr/bin/foo {
...
}
/usr/bin/foo {
...
}</pre><p>
Unattached profiles are never used automatically, nor can they be
transitioned to through a <code class="literal">px</code> rule. They need to be
attached to a program by either using a named profile transition (see
<a class="xref" href="cha.apparmor.profiles.html#sec.apparmor.profiles.exec.named" title="20.8.7. Named Profile Transitions">Section 20.8.7, “Named Profile Transitions”</a>) or with the
<code class="literal">change_profile</code> rule (see
<a class="xref" href="cha.apparmor.profiles.html#sec.apparmor.profiles.types.change" title="20.2.5. Change rules">Section 20.2.5, “Change rules”</a>).
</p><p>
Unattached profiles are useful for specialized profiles for system
utilities that generally should not be confined by a system wide profile
(for example, <code class="literal">/bin/bash</code>). They can also be used to
set up roles or to confine a user.
</p></div><div class="sect2" title="20.2.3. Local Profiles"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.types.local"></a>20.2.3. Local Profiles<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.types.local">¶</a></span></h3></div></div></div><p>
Local profiles provide a convenient way to provide specialized
confinement for utility programs launched by a confined application.
They are specified just like standard profiles except they are embedded
in a parent profile and begin with the <code class="literal">profile</code>
keyword:
</p><pre class="screen">/parent/profile {
...
profile local/profile {
...
}
}</pre><p>
To transition to a local profile, either use a <code class="literal">cx</code>
rule (see <a class="xref" href="cha.apparmor.profiles.html#sec.apparmor.profiles.exec.cx" title="20.8.2. Discrete Local Profile Execute Mode (cx)">Section 20.8.2, “Discrete Local Profile Execute Mode (cx)”</a>) or a named
profile transition (see
<a class="xref" href="cha.apparmor.profiles.html#sec.apparmor.profiles.exec.named" title="20.8.7. Named Profile Transitions">Section 20.8.7, “Named Profile Transitions”</a>).
</p></div><div class="sect2" title="20.2.4. Hats"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.types.hat"></a>20.2.4. Hats<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.types.hat">¶</a></span></h3></div></div></div><p>
AppArmor "hats" are a local profiles with some additional restrictions and
an implicit rule allowing for <code class="literal">change_hat</code> to be used
to transition to them. Refer to <a class="xref" href="cha.apparmor.hat.html" title="Chapter 24. Profiling Your Web Applications Using ChangeHat">Chapter 24, <i>Profiling Your Web Applications Using ChangeHat</i></a> for a
detailed description.
</p></div><div class="sect2" title="20.2.5. Change rules"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.types.change"></a>20.2.5. Change rules<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.types.change">¶</a></span></h3></div></div></div><p>
AppArmor provides <code class="literal">change_hat</code> and
<code class="literal">change_profile</code> rules that control domain
transitioning. <code class="literal">change_hat</code> are specified by defining
hats in a profile, while <code class="literal">change_profile</code> rules refer
to another profile and start with the keyword
<code class="literal">change_profile</code>:
</p><pre class="screen">change_profile /usr/bin/foobar,</pre><p>
Both <code class="literal">change_hat</code> and <code class="literal">change_profile</code>
provide for an application directed profile transition, without having
to launch a separate application. <code class="literal">change_profile</code>
provides a generic one way transition between any of the loaded
profiles. <code class="literal">change_hat</code> provides for a returnable parent
child transition where an application can switch from the parent profile
to the hat profile and if it provides the correct secret key return to
the parent profile at a later time.
</p><p>
<code class="literal">change_profile</code> is best used in situations where an
application goes through a trusted setup phase and then can lower its
privilege level. Any resources mapped or opened during the start-up
phase may still be accessible after the profile change, but the new
profile will restrict the opening of new resources, and will even limit
some of the resources opened before the switch. Specifically, memory
resources will still be available while capability and file resources
(as long as they are not memory mapped) can be limited.
</p><p>
<code class="literal">change_hat</code> is best used in situations where an
application runs a virtual machine or an interpreter that does not
provide direct access to the applications resources (e.g. Apache's
<code class="literal">mod_php</code>). Since <code class="literal">change_hat</code> stores
the return secret key in the application's memory the phase of reduced
privilege should not have direct access to memory. It is also important
that file access is properly separated, since the hat can restrict
accesses to a file handle but does not close it. If an application does
buffering and provides access to the open files with buffering, the
accesses to these files may not be seen by the kernel and hence not
restricted by the new profile.
</p><div class="warning"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Warning: Safety of Domain Transitions"><tr class="head"><td width="32"><img alt="[Warning]" src="admon/warning.png"></td><th align="left">Safety of Domain Transitions</th></tr><tr><td colspan="2" align="left" valign="top"><p>
The <code class="literal">change_hat</code> and <code class="literal">change_profile</code>
domain transitions are less secure than a domain transition done
through an exec because they do not affect a processes memory mappings,
nor do they close resources that have already been opened.
</p></td></tr></table></div></div></div><div class="sect1" title="20.3. #include Statements"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.profiles.includes"></a>20.3. <code class="literal">#include</code> Statements<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.includes">¶</a></span></h2></div></div></div><p>
<code class="literal">#include</code> statements are directives that pull in
components of other Novell AppArmor profiles to simplify profiles. Include files
retrieve access permissions for programs. By using an include, you can
give the program access to directory paths or files that are also
required by other programs. Using includes can reduce the size of a
profile.
</p><p>
By default, AppArmor adds <code class="filename">/etc/apparmor.d</code> to the path in
the <code class="literal">#include</code> statement. AppArmor expects the include files
to be located in <code class="filename">/etc/apparmor.d</code>. Unlike other
profile statements (but similar to C programs),
<code class="literal">#include</code> lines do not end with a comma.
</p><p>
To assist you in profiling your applications, Novell AppArmor provides three
classes of <code class="literal">#include</code>s: abstractions, program chunks and
tunables.
</p><div class="sect2" title="20.3.1. Abstractions"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.includes.abstractions"></a>20.3.1. Abstractions<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.includes.abstractions">¶</a></span></h3></div></div></div><p>
Abstractions are <code class="literal">#include</code>s that are grouped by common
application tasks. These tasks include access to authentication
mechanisms, access to name service routines, common graphics
requirements, and system accounting. Files listed in these abstractions
are specific to the named task. Programs that require one of these files
usually require some of the other files listed in the abstraction file
(depending on the local configuration as well as the specific
requirements of the program). Find abstractions in
<code class="filename">/etc/apparmor.d/abstractions</code>.
</p></div><div class="sect2" title="20.3.2. Program Chunks"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.includes.chunks"></a>20.3.2. Program Chunks<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.includes.chunks">¶</a></span></h3></div></div></div><p>
The program-chunks directory
(<code class="filename">/etc/apparmor.d/program-chunks</code>) contains some
chunks of profiles that are specific to program suites and not generally
useful outside of the suite, thus are never suggested for use in
profiles by the profile wizards (aa-logprof and aa-genprof). Currently,
program chunks are only available for the postfix program suite.
</p></div><div class="sect2" title="20.3.3. Tunables"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.includes.tunables"></a>20.3.3. Tunables<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.includes.tunables">¶</a></span></h3></div></div></div><p>
The tunables directory (<code class="filename">/etc/apparmor.d/tunables</code>)
contains global variable definitions. When used in a profile, these
variables expand to a value that can be changed without changing the
entire profile. Add all the tunables definitions that should be
available to every profile to
<code class="filename">/etc/apparmor.d/tunables/global</code>.
</p></div></div><div class="sect1" title="20.4. Capability Entries (POSIX.1e)"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.profiles.capabilities"></a>20.4. Capability Entries (POSIX.1e)<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.capabilities">¶</a></span></h2></div></div></div><p>
Capability statements are simply the word <code class="literal">capability</code>
followed by the name of the POSIX.1e capability as defined in the
<code class="systemitem">capabilities(7)</code> man page.
</p></div><div class="sect1" title="20.5. Network Access Control"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.profiles.nac"></a>20.5. Network Access Control<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.nac">¶</a></span></h2></div></div></div><p>
AppArmor allows mediation of network access based on the address type and
family. The following illustrates the network access rule syntax:
</p><pre class="screen">network [[<domain><a name="co.apparmor.profiles.nac.dom"></a><img src="callouts/1.png" alt="1" border="0">][<type<a name="co.apparmor.profiles.nac.type"></a><img src="callouts/2.png" alt="2" border="0">>][<protocol<a name="co.apparmor.profiles.nac.proto"></a><img src="callouts/3.png" alt="3" border="0">>]]</pre><div class="calloutlist"><table border="0" summary="Callout list"><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.nac.dom"><img src="callouts/1.png" alt="1" border="0"></a> </p></td><td valign="top" align="left"><p>
Supported domains: <code class="literal">inet</code>, <code class="literal">ax25</code>,
<code class="literal">ipx</code>, <code class="literal">appletalk</code>,
<code class="literal">netrom</code>, <code class="literal">bridge</code>,
<code class="literal">x25</code>, <code class="literal">inet6</code>,
<code class="literal">rose</code>, <code class="literal">netbeui</code>,
<code class="literal">security</code>, <code class="literal">key</code>,
<code class="literal">packet</code>, <code class="literal">ash</code>,
<code class="literal">econet</code>, <code class="literal">atmsvc</code>,
<code class="literal">sna</code>, <code class="literal">irda</code>,
<code class="literal">pppox</code>, <code class="literal">wanpipe</code>,
<code class="literal">bluetooth</code>
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.nac.type"><img src="callouts/2.png" alt="2" border="0"></a> </p></td><td valign="top" align="left"><p>
Supported types: <code class="literal">stream</code>, <code class="literal">dgram</code>,
<code class="literal">seqpacket</code>, <code class="literal">rdm</code>,
<code class="literal">raw</code>, <code class="literal">packet</code>
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.nac.proto"><img src="callouts/3.png" alt="3" border="0"></a> </p></td><td valign="top" align="left"><p>
Supported protocols: <code class="literal">tcp</code>, <code class="literal">udp</code>,
<code class="literal">icmp</code>
</p></td></tr></table></div><p>
The AppArmor tools support only family and type specification. The AppArmor
module emits only <code class="literal">network <em class="replaceable"><code>domain</code></em>
<em class="replaceable"><code>type</code></em></code> in <span class="quote">“<span class="quote">access denied</span>”</span>
messages. And only these are output by the profile generation tools, both
YaST and command line.
</p><p>
The following examples illustrate possible network-related rules to be
used in AppArmor profiles. Note that the syntax of the last two are not
currently supported by the AppArmor tools.
</p><pre class="screen">network<a name="co.apparmor.profiles.nac.nw"></a><img src="callouts/1.png" alt="1" border="0">,
network inet<a name="co.apparmor.profiles.nac.inet"></a><img src="callouts/2.png" alt="2" border="0">,
network inet6<a name="co.apparmor.profiles.nac.inet6"></a><img src="callouts/3.png" alt="3" border="0">,
network inet stream<a name="co.apparmor.profiles.nac.istream"></a><img src="callouts/4.png" alt="4" border="0">,
network inet tcp<a name="co.apparmor.profiles.nac.itcp"></a><img src="callouts/5.png" alt="5" border="0">,
network tcp<a name="co.apparmor.profiles.nac.tcp"></a><img src="callouts/6.png" alt="6" border="0">,
</pre><div class="calloutlist"><table border="0" summary="Callout list"><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.nac.nw"><img src="callouts/1.png" alt="1" border="0"></a> </p></td><td valign="top" align="left"><p>
Allow all networking. No restrictions applied with regards to domain,
type, or protocol.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.nac.inet"><img src="callouts/2.png" alt="2" border="0"></a> </p></td><td valign="top" align="left"><p>
Allow general use of IPv4 networking.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.nac.inet6"><img src="callouts/3.png" alt="3" border="0"></a> </p></td><td valign="top" align="left"><p>
Allow general use of IPv6 networking.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.nac.istream"><img src="callouts/4.png" alt="4" border="0"></a> </p></td><td valign="top" align="left"><p>
Allow the use of IPv4 TCP networking.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.nac.itcp"><img src="callouts/5.png" alt="5" border="0"></a> </p></td><td valign="top" align="left"><p>
Allow the use of IPv4 TCP networking, paraphrasing the rule above.
</p></td></tr><tr><td width="5%" valign="top" align="left"><p><a href="#co.apparmor.profiles.nac.tcp"><img src="callouts/6.png" alt="6" border="0"></a> </p></td><td valign="top" align="left"><p>
Allow the use of both IPv4 and IPv6 TCP networking.
</p></td></tr></table></div></div><div class="sect1" title="20.6. Paths and Globbing"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.profiles.glob"></a>20.6. Paths and Globbing<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.glob">¶</a></span></h2></div></div></div><p>
AppArmor explicitly distinguishes directory path names from file path names.
Use a trailing <code class="literal">/</code> for any directory path that needs to
be explicitly distinguished:
</p><div class="variablelist"><dl><dt><span class="term"><code class="filename">/some/random/example/* r</code>
</span></dt><dd><p>
Allow read access to files in the
<code class="filename">/some/random/example</code> directory.
</p></dd><dt><span class="term"><code class="filename">/some/random/example/ r</code>
</span></dt><dd><p>
Allow read access to the directory only.
</p></dd><dt><span class="term"><code class="filename">/some/**/ r</code>
</span></dt><dd><p>
Give read access to any directories below <code class="filename">/some</code>.
</p></dd><dt><span class="term"><code class="filename">/some/random/example/** r</code>
</span></dt><dd><p>
Give read access to files and directories under
<code class="filename">/some/random/example</code>.
</p></dd><dt><span class="term"><code class="filename">/some/random/example/**[^/] r</code>
</span></dt><dd><p>
Give read access to files under
<code class="filename">/some/random/example</code>. Explicitly exclude
directories (<code class="literal">[^/]</code>).
</p></dd></dl></div><p>
Globbing (or regular expression matching) is when you modify the
directory path using wild cards to include a group of files or
subdirectories. File resources can be specified with a globbing syntax
similar to that used by popular shells, such as csh, Bash, and zsh.
</p><div class="informaltable"><table border="1"><colgroup><col><col></colgroup><tbody><tr><td>
<p>
<code class="literal">*</code>
</p>
</td><td>
<p>
Substitutes for any number of any characters, except
<code class="literal">/</code>.
</p>
<p>
Example: An arbitrary number of file path elements.
</p>
</td></tr><tr><td>
<p>
<code class="literal">**</code>
</p>
</td><td>
<p>
Substitutes for any number of characters, including
<code class="literal">/</code>.
</p>
<p>
Example: An arbitrary number of path elements, including entire
directories.
</p>
</td></tr><tr><td>
<p>
<code class="literal">?</code>
</p>
</td><td>
<p>
Substitutes for any single character, except <code class="literal">/</code>.
</p>
</td></tr><tr><td>
<p>
<code class="literal">[abc]</code>
</p>
</td><td>
<p>
Substitutes for the single character <code class="literal">a</code>,
<code class="literal">b</code>, or <code class="literal">c</code>.
</p>
<p>
Example: a rule that matches <code class="literal">/home[01]/*/.plan</code>
allows a program to access <code class="filename">.plan</code> files for
users in both <code class="filename">/home0</code> and
<code class="filename">/home1</code>.
</p>
</td></tr><tr><td>
<p>
<code class="literal">[a-c]</code>
</p>
</td><td>
<p>
Substitutes for the single character <code class="literal">a</code>,
<code class="literal">b</code>, or <code class="literal">c</code>.
</p>
</td></tr><tr><td>
<p>
<code class="literal">{ab,cd}</code>
</p>
</td><td>
<p>
Expands to one rule to match <code class="literal">ab</code> and one rule to
match <code class="literal">cd</code>.
</p>
<p>
Example: a rule that matches <code class="literal">/{usr,www}/pages/**</code>
grants access to Web pages in both <code class="filename">/usr/pages</code>
and <code class="filename">/www/pages</code>.
</p>
</td></tr><tr><td>
<p>
<code class="literal">[ ^a ]</code>
</p>
</td><td>
<p>
Substitutes for any character except <code class="literal">a</code>.
</p>
</td></tr></tbody></table></div><div class="sect2" title="20.6.1. Using Variables in Profiles"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.glob.variables"></a>20.6.1. Using Variables in Profiles<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.glob.variables">¶</a></span></h3></div></div></div><p>
AppArmor allows to use variables holding paths in profiles. Use global
variables to make your profiles portable and local variables to create
shortcuts for paths.
</p><p>
A typical example of when global variables come in handy are network
scenarios in which user home directories are mounted in different
locations. Instead of rewriting paths to home directories in all
affected profiles, you only need to change the value of a variable.
Global variables are defined under
<code class="filename">/etc/apparmor.d/tunables</code> and have to be made
available via an <code class="literal">#include</code> statement. Find the
variable definitions for this use case (<code class="envar">@{HOME}</code> and
<code class="envar">@{HOMEDIRS}</code>) in the
<code class="filename">/etc/apparmor.d/tunables/home</code> file.
</p><p>
Local variables are defined at the head of a profile. This is useful to
provide the base of for a chrooted path, for example:
</p><pre class="screen">@{CHROOT_BASE}=/tmp/foo
/sbin/syslog-ng {
...
# chrooted applications
@{CHROOT_BASE}/var/lib/*/dev/log w,
@{CHROOT_BASE}/var/log/** w,
...
}</pre><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>
With the current AppArmor tools, variables can only be used when manually
editing and maintaining a profile.
</p></td></tr></table></div></div><div class="sect2" title="20.6.2. Alias rules"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.glob.alias"></a>20.6.2. Alias rules<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.glob.alias">¶</a></span></h3></div></div></div><p>
Alias rules provide an alternative way to manipulate profile path
mappings to site specific layouts. They are an alternative form of path
rewriting to using variables, and are done post variable resolution:
</p><pre class="screen">alias /home/ -> /mnt/users/</pre><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>
With the current AppArmor tools, alias rules can only be used when manually
editing and maintaining a profile. Whats more, they are deactivated by
disabled. Enable alias rules by editing
<code class="filename">/etc/apparmor.d/tunables/alias</code>
</p></td></tr></table></div></div></div><div class="sect1" title="20.7. File Permission Access Modes"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.profiles.perm"></a>20.7. File Permission Access Modes<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.perm">¶</a></span></h2></div></div></div><p>
File permission access modes consist of combinations of the following
modes:
</p><div class="informaltable"><table border="1"><colgroup><col><col></colgroup><tbody><tr><td>
<p>
<code class="literal">r</code>
</p>
</td><td>
<p>
Read mode
</p>
</td></tr><tr><td>
<p>
<code class="literal">w</code>
</p>
</td><td>
<p>
Write mode (mutually exclusive to <code class="literal">a</code>)
</p>
</td></tr><tr><td>
<p>
<code class="literal">a</code>
</p>
</td><td>
<p>
Append mode (mutually exclusive to <code class="literal">w</code>)
</p>
</td></tr><tr><td>
<p>
<code class="literal">k</code>
</p>
</td><td>
<p>
File locking mode
</p>
</td></tr><tr><td>
<p>
<code class="literal">l</code>
</p>
</td><td>
<p>
Link mode
</p>
</td></tr><tr><td>
<p>
<code class="literal">link <em class="replaceable"><code>file</code></em> ->
<em class="replaceable"><code>target</code></em></code>
</p>
</td><td>
<p>
Link pair rule (cannot be combined with other access modes)
</p>
</td></tr></tbody></table></div><div class="sect2" title="20.7.1. Read Mode (r)"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.perm.r"></a>20.7.1. Read Mode (r)<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.perm.r">¶</a></span></h3></div></div></div><p>
Allows the program to have read access to the resource. Read access is
required for shell scripts and other interpreted content and determines
if an executing process can core dump.
</p></div><div class="sect2" title="20.7.2. Write Mode (w)"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.perm.w"></a>20.7.2. Write Mode (w)<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.perm.w">¶</a></span></h3></div></div></div><p>
Allows the program to have write access to the resource. Files must have
this permission if they are to be unlinked (removed).
</p></div><div class="sect2" title="20.7.3. Append Mode (a)"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.perm.a"></a>20.7.3. Append Mode (a)<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.perm.a">¶</a></span></h3></div></div></div><p>
Allows a program to write to the end of a file. In contrast to the
<code class="literal">w</code> mode, the append mode does not include the ability
to overwrite data, to rename, or to remove a file. The append permission
is typically used with applications who need to be able to write to log
files, but which should not be able to manipulate any existing data in
the log files. As the append permission is just a subset of the
permissions associated with the write mode, the <code class="literal">w</code> and
<code class="literal">a</code> permission flags cannot be used together and are
mutually exclusive.
</p></div><div class="sect2" title="20.7.4. File Locking Mode (k)"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.perm.k"></a>20.7.4. File Locking Mode (k)<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.perm.k">¶</a></span></h3></div></div></div><p>
The application can take file locks. Former versions of AppArmor allowed
files to be locked if an application had access to them. By using a
separate file locking mode, AppArmor makes sure locking is restricted only
to those files which need file locking and tightens security as locking
can be used in several denial of service attack scenarios.
</p></div><div class="sect2" title="20.7.5. Link Mode (l)"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.perm.link"></a>20.7.5. Link Mode (l)<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.perm.link">¶</a></span></h3></div></div></div><p>
The link mode mediates access to hard links. When a link is created, the
target file must have the same access permissions as the link created
(with the exception that the destination does not need link access).
</p></div><div class="sect2" title="20.7.6. Link Pair"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.perm.link_pair"></a>20.7.6. Link Pair<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.perm.link_pair">¶</a></span></h3></div></div></div><p>
The link mode grants permission to create links to arbitrary files,
provided the link has a subset of the permissions granted by the target
(subset permission test). By specifying origin and destination, the link
pair rule provides greater control over how hard links are created. Link
pair rules by default do not enforce the link subset permission test
that the standard rules link permission requires. To force the rule to
require the test the <code class="literal">subset</code> keyword is used. The
following rules are equivalent:
</p><pre class="screen">/link l,
link subset /link -> /**,
</pre><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>
Currently link pair rules are not supported by YaST and the command
line tools. Manually edit your profiles to use them. Updating such
profiles using the tools is safe, because the link pair entries will
not be touched.
</p></td></tr></table></div></div><div class="sect2" title="20.7.7. Owner Conditional Rules"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.perm.owner"></a>20.7.7. Owner Conditional Rules<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.perm.owner">¶</a></span></h3></div></div></div><p>
The file rules can be extended so that they can be conditional upon the
the user being the owner of the file (the fsuid has to match the file's
uid). For this purpose the <code class="literal">owner</code> keyword is prepended
to the rule. Owner conditional rules accumulate just as regular file
rules.
</p><pre class="screen">owner /home/*/** rw</pre><p>
When using file ownership conditions with link rules the ownership test
is done against the target file so the user must own the file to be able
to link to it.
</p><div class="note"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Note: Precedence of Regular File Rules"><tr class="head"><td width="32"><img alt="[Note]" src="admon/note.png"></td><th align="left">Precedence of Regular File Rules</th></tr><tr><td colspan="2" align="left" valign="top"><p>
Owner conditional rules are considered a subset of regular file rules.
If a regular file rule overlaps with an owner conditional file rule,
the resultant permissions will be that of the regular file rule.
</p></td></tr></table></div></div><div class="sect2" title="20.7.8. Deny Rules"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.perm.deny"></a>20.7.8. Deny Rules<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.perm.deny">¶</a></span></h3></div></div></div><p>
Deny rules can be used to annotate or quiet known rejects. The profile
generating tools will not ask about a known reject treated with a deny
rule. Such a reject will also not show up in the audit logs when denied,
keeping the log files lean. If this is not desired, prepend the deny
entry with the keyword <code class="literal">audit</code>.
</p><p>
It is also possible to use deny rules in combination with allow rules.
This allows you to specify a broad allow rule, and then subtract a few
known files that should not be allowed. Deny rules can also be combined
with owner rules, to deny files owned by the user. The following example
allows read/write access to everything in a users directory except write
access to the .ssh/ files:
</p><pre class="screen">deny /home/*/.ssh/** w,
/home/*/** rw,</pre><p>
The extensive use of deny rules is generally not encouraged, because it
makes it much harder to understand what a profile does. However a
judicious use of deny rules can simplify profiles. Therefore the tools
only generate profiles denying specific files and will not make use of
globbing in deny rules. Manually edit your profiles to add deny rules
using globbing. Updating such profiles using the tools is safe, because
the deny entries will not be touched.
</p></div></div><div class="sect1" title="20.8. Execute Modes"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.profiles.exec"></a>20.8. Execute Modes<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.exec">¶</a></span></h2></div></div></div><p>
Execute modes, also named profile transitions, consist of the following
modes:
</p><div class="informaltable"><table border="1"><colgroup><col><col></colgroup><tbody><tr><td>
<p>
<code class="literal">px</code>
</p>
</td><td>
<p>
Discrete profile execute mode
</p>
</td></tr><tr><td>
<p>
<code class="literal">cx</code>
</p>
</td><td>
<p>
Discrete local profile execute mode
</p>
</td></tr><tr><td>
<p>
<code class="literal">ux</code>
</p>
</td><td>
<p>
Unconstrained execute mode
</p>
</td></tr><tr><td>
<p>
<code class="literal">ix</code>
</p>
</td><td>
<p>
Inherit execute mode
</p>
</td></tr><tr><td>
<p>
<code class="literal">m</code>
</p>
</td><td>
<p>
Allow <code class="literal">PROT_EXEC</code> with <span class="command"><strong>mmap(2)</strong></span>
calls
</p>
</td></tr></tbody></table></div><div class="sect2" title="20.8.1. Discrete Profile Execute Mode (px)"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.exec.px"></a>20.8.1. Discrete Profile Execute Mode (px)<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.exec.px">¶</a></span></h3></div></div></div><p>
This mode requires that a discrete security profile is defined for a
resource executed at an AppArmor domain transition. If there is no profile
defined, the access is denied.
</p><div class="warning"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Warning: Using the Discrete Profile Execute Mode"><tr class="head"><td width="32"><img alt="[Warning]" src="admon/warning.png"></td><th align="left">Using the Discrete Profile Execute Mode</th></tr><tr><td colspan="2" align="left" valign="top"><p>
<code class="literal">px</code> does not scrub the environment of variables such
as <code class="envar">LD_PRELOAD</code>. As a result, the calling domain may have
an undue amount of influence over the called item.
</p></td></tr></table></div><p>
Incompatible with <code class="literal">Ux</code>, <code class="literal">ux</code>,
<code class="literal">Px</code>, and <code class="literal">ix</code>.
</p></div><div class="sect2" title="20.8.2. Discrete Local Profile Execute Mode (cx)"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.exec.cx"></a>20.8.2. Discrete Local Profile Execute Mode (cx)<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.exec.cx">¶</a></span></h3></div></div></div><p>
As <code class="literal">px</code>, but instead of searching the global profile
set, <code class="literal">cx</code> only searches the local profiles of the
current profile. This profile transition provides a way for an
application to have alternate profiles for helper applications.
</p><div class="note"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Note: Limitations of the Discrete Local Profile Execute Mode (cx)"><tr class="head"><td width="32"><img alt="[Note]" src="admon/note.png"></td><th align="left">Limitations of the Discrete Local Profile Execute Mode (cx)</th></tr><tr><td colspan="2" align="left" valign="top"><p>
Currently, cx transitions are limited to top level profiles and can not
be used in hats and children profiles. This restriction will be removed
in the future.
</p></td></tr></table></div><p>
Incompatible with <code class="literal">Ux</code>, <code class="literal">ux</code>,
<code class="literal">Px</code>, <code class="literal">px</code>, <code class="literal">Cx</code>, and
<code class="literal">ix</code>.
</p></div><div class="sect2" title="20.8.3. Unconstrained Execute Mode (ux)"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.exec.ux"></a>20.8.3. Unconstrained Execute Mode (ux)<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.exec.ux">¶</a></span></h3></div></div></div><p>
Allows the program to execute the resource without any AppArmor profile
applied to the executed resource. This mode is useful when a confined
program needs to be able to perform a privileged operation, such as
rebooting the machine. By placing the privileged section in another
executable and granting unconstrained execution rights, it is possible
to bypass the mandatory constraints imposed on all confined processes.
For more information about what is constrained, see the
<code class="systemitem">apparmor(7)</code> man page.
</p><div class="warning"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Warning: Using Unconstrained Execute Mode (ux)"><tr class="head"><td width="32"><img alt="[Warning]" src="admon/warning.png"></td><th align="left">Using Unconstrained Execute Mode (ux)</th></tr><tr><td colspan="2" align="left" valign="top"><p>
Use <code class="literal">ux</code> only in very special cases. It enables the
designated child processes to be run without any AppArmor protection.
<code class="literal">ux</code> does not scrub the environment of variables such
as <code class="envar">LD_PRELOAD</code>. As a result, the calling domain may have
an undue amount of influence over the called resource. Use this mode
only if the child absolutely must be run unconfined and
<code class="envar">LD_PRELOAD</code> must be used. Any profile using this mode
provides negligible security. Use at your own risk.
</p></td></tr></table></div><p>
This mode is incompatible with <code class="literal">Ux</code>,
<code class="literal">px</code>, <code class="literal">Px</code>, and <code class="literal">ix</code>.
</p></div><div class="sect2" title="20.8.4. Clean Exec modes"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.exec.clean"></a>20.8.4. Clean Exec modes<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.exec.clean">¶</a></span></h3></div></div></div><p>
The clean exec modes allow the named program to run in
<code class="literal">px</code>, <code class="literal">cx</code> and <code class="literal">ux</code>
mode, but AppArmor invokes the Linux kernel's <span class="command"><strong>unsafe_exec</strong></span>
routines to scrub the environment, similar to setuid programs. The clean
exec modes are specified with an uppercase letter:
<code class="literal">Px</code>, <code class="literal">Cx</code> and <code class="literal">Ux</code>.
See the man page of <span class="command"><strong>ld.so(8)</strong></span> for some information
about setuid and setgid environment scrubbing.
</p></div><div class="sect2" title="20.8.5. Inherit Execute Mode (ix)"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.exec.ix"></a>20.8.5. Inherit Execute Mode (ix)<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.exec.ix">¶</a></span></h3></div></div></div><p>
<code class="literal">ix</code> prevents the normal AppArmor domain transition on
<span class="command"><strong>execve(2)</strong></span> when the profiled program executes the
named program. Instead, the executed resource inherits the current
profile.
</p><p>
This mode is useful when a confined program needs to call another
confined program without gaining the permissions of the target's profile
or losing the permissions of the current profile. There is no version to
scrub the environment because <code class="literal">ix</code> executions do not
change privileges.
</p><p>
Incompatible with <code class="literal">cx</code>, <code class="literal">ux</code>, and
<code class="literal">px</code>. Implies <code class="literal">m</code>.
</p></div><div class="sect2" title="20.8.6. Allow Executable Mapping (m)"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.exec.m"></a>20.8.6. Allow Executable Mapping (m)<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.exec.m">¶</a></span></h3></div></div></div><p>
This mode allows a file to be mapped into memory using
<span class="command"><strong>mmap(2)</strong></span>'s <code class="envar">PROT_EXEC</code> flag. This flag
marks the pages executable. It is used on some architectures to provide
non executable data pages, which can complicate exploit attempts. AppArmor
uses this mode to limit which files a well-behaved program (or all
programs on architectures that enforce non executable memory access
controls) may use as libraries, to limit the effect of invalid
<code class="option">-L</code> flags given to <span class="command"><strong>ld(1)</strong></span> and
<code class="envar">LD_PRELOAD</code>, <code class="envar">LD_LIBRARY_PATH</code>, given to
<span class="command"><strong>ld.so(8)</strong></span>.
</p></div><div class="sect2" title="20.8.7. Named Profile Transitions"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.exec.named"></a>20.8.7. Named Profile Transitions<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.exec.named">¶</a></span></h3></div></div></div><p>
By default, the <code class="literal">px</code> and <code class="literal">cx</code> (and
their clean exec variants, too) transition to a profile who's name
matches the executable name. With named profile transitions, you can
specify a profile to be transitioned to. This is useful if multiple
binaries need to share a single profile, or if they need to use a
different profile than their name would specify. Named profile
transitions can be used in conjunction with <code class="literal">cx</code>,
<code class="literal">Cx</code>, <code class="literal">px</code> and <code class="literal">Px</code>.
Currently there is a limit of twelve named profile transitions per
profile.
</p><p>
Named profile transitions use <code class="literal">-></code> to indicate the name
of the profile that needs to be transitioned to:
</p><pre class="screen">/usr/bin/foo
{
/bin/** px -> shared_profile,
...
/usr/*bash cx -> local_profile,
...
profile local_profile
{
...
}
}
</pre><div class="note"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Note: Difference Between Normal and Named Transitions"><tr class="head"><td width="32"><img alt="[Note]" src="admon/note.png"></td><th align="left">Difference Between Normal and Named Transitions</th></tr><tr><td colspan="2" align="left" valign="top"><p>
When used with globbing, normal transitions provide a <span class="quote">“<span class="quote">one to
many</span>”</span> relationship—<code class="literal">/bin/** px</code> will
transition to <code class="filename">/bin/ping</code>,
<code class="filename">/bin/cat</code>, etc, depending on the program being run.
</p><p>
Named transitions provide a <span class="quote">“<span class="quote">many to one</span>”</span>
relationship—all programs that match the rule regardless of their
name will transition to the specified profile.
</p><p>
Named profile transitions show up in the log as having the mode
<code class="literal">Nx</code>. The name of the profile to be changed to is
listed in the <code class="literal">name2</code> field.
</p></td></tr></table></div></div><div class="sect2" title="20.8.8. Inheritance Fallback for Profile Transitions"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.exec.fallback"></a>20.8.8. Inheritance Fallback for Profile Transitions<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.exec.fallback">¶</a></span></h3></div></div></div><p>
The <code class="literal">px</code> and <code class="literal">cx</code> transitions specify
a hard dependency (if the specified profile does not exist, the exec
will fail). With the inheritance fallback, the execution will succeed
but inherit the current profile. To specify inheritance fallback,
<code class="literal">ix</code> is combined with <code class="literal">cx</code>,
<code class="literal">Cx</code>, <code class="literal">px</code> and <code class="literal">Px</code>
into the modes <code class="literal">cix</code>, <code class="literal">Cix</code>,
<code class="literal">pix</code> and <code class="literal">Pix</code>. The fallback modes
can be used with named profile transitions, too.
</p></div><div class="sect2" title="20.8.9. Variable Settings in Execution Modes"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.profiles.exec.variables"></a>20.8.9. Variable Settings in Execution Modes<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.exec.variables">¶</a></span></h3></div></div></div><p>
When choosing one of the Px, Cx or Ux execution modes, take into account
that the following environment variables are removed from the
environment before the child process inherits it. As a consequence,
applications or processes relying on any of these variables do not work
anymore if the profile applied to them carries Px, Cx or Ux flags:
</p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">GCONV_PATH</code>
</p></li><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">GETCONF_DIR</code>
</p></li><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">HOSTALIASES</code>
</p></li><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">LD_AUDIT</code>
</p></li><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">LD_DEBUG</code>
</p></li><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">LD_DEBUG_OUTPUT</code>
</p></li><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">LD_DYNAMIC_WEAK</code>
</p></li><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">LD_LIBRARY_PATH</code>
</p></li><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">LD_ORIGIN_PATH</code>
</p></li><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">LD_PRELOAD</code>
</p></li><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">LD_PROFILE</code>
</p></li><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">LD_SHOW_AUXV</code>
</p></li><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">LD_USE_LOAD_BIAS</code>
</p></li><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">LOCALDOMAIN</code>
</p></li><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">LOCPATH</code>
</p></li><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">MALLOC_TRACE</code>
</p></li><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">NLSPATH</code>
</p></li><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">RESOLV_HOST_CONF</code>
</p></li><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">RES_OPTIONS</code>
</p></li><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">TMPDIR</code>
</p></li><li class="listitem" style="list-style-type: disc"><p>
<code class="envar">TZDIR</code>
</p></li></ul></div></div></div><div class="sect1" title="20.9. Resource Limit Control"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.profiles.rlimit"></a>20.9. Resource Limit Control<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.rlimit">¶</a></span></h2></div></div></div><p>
AppArmor provides the ability to set and control an application's resource
limits (rlimits, also known as ulimits). By default AppArmor does not control
applications rlimits, and it will only control those limits specified in
the confining profile. For more information about resource limits, refer
to the <code class="systemitem">setrlimit(2)</code>,
<code class="systemitem">ulimit(1)</code>, or <code class="systemitem">ulimit(3)</code>
man pages.
</p><p>
AppArmor leverages the system's rlimits and as such does not provide an
additional auditing that would normally occur. It also cannot raise
rlimits set by the system, AppArmor rlimits can only reduce an application's
current resource limits.
</p><p>
The values will be inherited by the children of a process and will remain
even if a new profile is transitioned to or the application becomes
unconfined. So when an application transitions to a new profile, that
profile has the ability to further reduce the applications rlimits.
</p><p>
AppArmor's rlimit rules will also provide mediation of setting an
application's hard limits, should it try to raise them. The application
will not be able to raise its hard limits any further than specified in
the profile. The mediation of raising hard limits is not inherited as the
set value is, so that once the application transitions to a new profile
it is free to raise its limits as specified in the profile.
</p><p>
AppArmor's rlimit control does not affect an application's soft limits beyond
ensuring that they are less than or equal to the application's hard
limits.
</p><p>
AppArmor's hard limit rules have the general form of:
</p><pre class="screen">set rlimit <em class="replaceable"><code>resource</code></em> <= <em class="replaceable"><code>value</code></em>,</pre><p>
where <em class="replaceable"><code>resource</code></em> and
<em class="replaceable"><code>value</code></em> are to be replaced with the following
values:
</p><div class="variablelist"><dl><dt><span class="term"><code class="literal">cpu</code>
</span></dt><dd><p>
currently not supported
</p></dd><dt><span class="term"><code class="literal">fsize</code>, <code class="literal">data</code>, <code class="literal">stack</code>,
<code class="literal">core</code>, <code class="literal">rss</code>, <code class="literal">as</code>,
<code class="literal">memlock</code>, <code class="literal">msgqueue</code>
</span></dt><dd><p>
a number in bytes, or a number with a suffix where the suffix can be K
(kilobytes), M (megabytes), G (gigabytes), for example
</p><pre class="screen">rlimit data <= 100M,</pre></dd><dt><span class="term"><code class="literal">fsize</code>, <code class="literal">nofile</code>, <code class="literal">locks</code>,
<code class="literal">sigpending</code>, <code class="literal">nproc</code><sup>*</sup>,
<code class="literal">rtprio</code>
</span></dt><dd><p>
a number greater or equal to 0
</p></dd><dt><span class="term"><code class="literal">nice</code>
</span></dt><dd><p>
a value between -20 and 19
</p></dd></dl></div><p>
<sup>*</sup>The nproc rlimit is handled different than
all the other rlimits. Instead of indicating the standard process rlimit
it controls the maximum number of processes that can be running under the
profile at any given time. Once the limit is exceeded the creation of new
processes under the profile will fail until the number of currently
running processes is reduced.
</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>
Currently the tools can not be used to add rlimit rules to profiles. The
only way to add rlimit controls to a profile is to manually edit the
profile with a text editor. The tools will still work with profiles
containing rlimit rules and will not remove them, so it is safe to use
the tools to update profiles containing them.
</p></td></tr></table></div></div><div class="sect1" title="20.10. Auditing Rules"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.profiles.audit"></a>20.10. Auditing Rules<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.audit">¶</a></span></h2></div></div></div><p>
AppArmor provides the ability to audit given rules so that when they are
matched an audit message will appear in the audit log. To enable audit
messages for a given rule, the <code class="literal">audit</code> keyword is
prepended to the rule:
</p><pre class="screen">audit /etc/foo/* rw,</pre><p>
If it is desirable to audit only a given permission the rule can be split
into two rules. The following example will result in audit messages when
files are opened for writing, but not when they are opened for just
reading:
</p><pre class="screen">audit /etc/foo/* w,
/etc/foo/* r,</pre><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>
Audit messages are not generated for every read or write of a file but
only when a file is opened for read or write.
</p></td></tr></table></div><p>
Audit control can be combined with owner conditional file rules to
provide auditing when users access files they own (at the moment it is
not possible to audit files they don't own):
</p><pre class="screen">audit owner /home/*/.ssh/** rw,</pre></div><div class="sect1" title="20.11. Setting Capabilities per Profile"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.profiles.set_capabilities"></a>20.11. Setting Capabilities per Profile<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.profiles.set_capabilities">¶</a></span></h2></div></div></div><p>
Normally AppArmor only restricts existing native Linux controls and does not
grant additional privileges. Therefore a program, having been granted
write access to a file via its profile, would not be able to actually
write to this file as long as the mode bits are set to read only.
</p><p>
The only exception to this strict rule is the <code class="literal">set
capability</code> rule. This provides the ability to give non-root
users administrative privileges, as defined in the
<code class="systemitem">capabilities(7)</code> man page. Contrary to setting a
program to setuid or using file system capabilities (that apply to single
programs only), the set capability rule allows the user to apply
capabilities to multiple programs running under a specific profile (by
using ix transitions). For security reasons, set capability rules will
not be inherited (once a program leaves the profile, it loses the
elevated privilege).
</p><div class="warning"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Warning: Use set capabilities Rules with Extreme Caution"><tr class="head"><td width="32"><img alt="[Warning]" src="admon/warning.png"></td><th align="left">Use set capabilities Rules with Extreme Caution</th></tr><tr><td colspan="2" align="left" valign="top"><p>
Using the set capabilities rules allows to give processes <code class="systemitem">root</code>
privileges. Therefore these rules should be used with extreme caution
and only in exceptional cases.
</p></td></tr></table></div><p>
To set a capability in a profile the keyword <span class="quote">“<span class="quote">set</span>”</span> is
prepended to a capability rule. Setting a capability also implicitly adds
a capability rule allowing that capability.
</p><pre class="screen">set capability cap_chown,</pre><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>
Currently the tools can not be used to add rlimit rules to profiles. The
only way to add rlimit controls to a profile is to manually edit the
profile with a text editor. The tools will still work with profiles
containing rlimit rules and will not remove them, so it is safe to use
the tools to update profiles containing them.
</p></td></tr></table></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 19. Immunizing Programs" href="cha.apparmor.concept.html"><span>◀</span></a> <a accesskey="n" title="Chapter 21. AppArmor Profile Repositories" href="cha.apparmor.repos.html"><span>▶</span></a></strong></p></div></td></tr></table></div></body></html>
ACC SHELL 2018