ACC SHELL

Path : /usr/share/doc/manual/opensuse-manuals_en/manual/
File Upload :
Current File : //usr/share/doc/manual/opensuse-manuals_en/manual/cha.apparmor.commandline.html

<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 23. Building Profiles from the Command Line</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.yast.html" title="Chapter 22. Building and Managing Profiles with YaST"><link rel="next" href="cha.apparmor.hat.html" title="Chapter 24. Profiling Your Web Applications Using ChangeHat"></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"> &gt; </span><a href="book.security.html">Security Guide</a><span class="breadcrumbs-sep"> &gt; </span><a href="part.apparmor.html">Confining Privileges with Novell AppArmor</a><span class="breadcrumbs-sep"> &gt; </span><strong><a accesskey="p" title="Chapter 22. Building and Managing Profiles with YaST" href="cha.apparmor.yast.html"><span>&#9664;</span></a>  <a accesskey="n" title="Chapter 24. Profiling Your Web Applications Using ChangeHat" href="cha.apparmor.hat.html"><span>&#9654;</span></a></strong></p></div></td></tr></table></div><div class="chapter" title="Chapter 23. Building Profiles from the Command Line"><div class="titlepage"><div><div><h2 class="title"><a name="cha.apparmor.commandline"></a>Chapter 23. Building Profiles from the Command Line<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#cha.apparmor.commandline">¶</a></span></h2></div></div></div><div class="toc"><p><b>Contents</b></p><dl><dt><span class="sect1"><a href="cha.apparmor.commandline.html#sec.apparmor.commandline.status">23.1. Checking the AppArmor Module Status</a></span></dt><dt><span class="sect1"><a href="cha.apparmor.commandline.html#sec.apparmor.commandline.build">23.2. Building AppArmor Profiles</a></span></dt><dt><span class="sect1"><a href="cha.apparmor.commandline.html#sec.apparmor.commandline.add">23.3. Adding or Creating an AppArmor Profile</a></span></dt><dt><span class="sect1"><a href="cha.apparmor.commandline.html#sec.apparmor.commandline.edit">23.4. Editing an AppArmor Profile</a></span></dt><dt><span class="sect1"><a href="cha.apparmor.commandline.html#sec.apparmor.commandline.del">23.5. Deleting an AppArmor Profile</a></span></dt><dt><span class="sect1"><a href="cha.apparmor.commandline.html#sec.apparmor.commandline.profiling">23.6. Two Methods of Profiling</a></span></dt><dt><span class="sect1"><a href="cha.apparmor.commandline.html#sec.apparmor.commandline.filenames">23.7. Important Filenames and Directories</a></span></dt></dl></div><p>
  Novell® AppArmor provides the user the ability to use a command line interface
  rather than a graphical interface to manage and configure the system
  security. Track the status of Novell AppArmor and create, delete, or modify AppArmor
  profiles using the AppArmor command line tools.
 </p><div class="tip"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Tip: Background Information"><tr class="head"><td width="32"><img alt="[Tip]" src="admon/tip.png"></td><th align="left">Background Information</th></tr><tr><td colspan="2" align="left" valign="top"><p>
   Before starting to manage your profiles using the AppArmor command line
   tools, check out the general introduction to AppArmor given in
   <a class="xref" href="cha.apparmor.concept.html" title="Chapter 19. Immunizing Programs">Chapter 19, <i>Immunizing Programs</i></a> and
   <a class="xref" href="cha.apparmor.profiles.html" title="Chapter 20. Profile Components and Syntax">Chapter 20, <i>Profile Components and Syntax</i></a>.
  </p></td></tr></table></div><div class="sect1" title="23.1. Checking the AppArmor Module Status"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.commandline.status"></a>23.1. Checking the AppArmor Module Status<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.commandline.status">¶</a></span></h2></div></div></div><p>
   An AppArmor module can be in any one of three states:
  </p><div class="variablelist"><dl><dt><span class="term">Unloaded</span></dt><dd><p>
      The AppArmor module is not loaded into the kernel.
     </p></dd><dt><span class="term">Running</span></dt><dd><p>
      The AppArmor module is loaded into the kernel and is enforcing AppArmor
      program policies.
     </p></dd><dt><span class="term">Stopped</span></dt><dd><p>
      The AppArmor module is loaded into the kernel, but no policies are
      enforced.
     </p></dd></dl></div><p>
   Detect the state of the AppArmor module by inspecting
   <code class="filename">/sys/kernel/security/apparmor/profiles</code>. If
   <span class="command"><strong>cat /sys/kernel/security/apparmor/profiles</strong></span> reports a
   list of profiles, AppArmor is running. If it is empty and returns nothing,
   AppArmor is stopped. If the file does not exist, AppArmor is unloaded.
  </p><p>
   Manage AppArmor through the script <code class="filename">rcapparmor</code>, which can
   perform the following operations:
  </p><div class="variablelist"><dl><dt><span class="term"><span class="command"><strong>rcapparmor start</strong></span>
    </span></dt><dd><p>
      Behavior depends on the AppArmor module state. If it is unloaded,
      <code class="option">start</code> loads the module and starts it, putting it in
      the running state. If it is stopped, <code class="option">start</code> causes the
      module to rescan the AppArmor profiles usually found in
      <code class="filename">/etc/apparmor.d</code> and puts the module in the
      running state. If the module is already running,
      <code class="option">start</code> reports a warning and takes no action.
     </p></dd><dt><span class="term"><span class="command"><strong>rcapparmor stop</strong></span>
    </span></dt><dd><p>
      Stops the AppArmor module if it is running by removing all profiles from
      kernel memory, effectively disabling all access controls, and putting
      the module into the stopped state. If the AppArmor module is unloaded or
      already stopped, <code class="option">stop</code> tries to unload the profiles
      again, but nothing happens.
     </p></dd><dt><span class="term"><span class="command"><strong>rcapparmor restart</strong></span>
    </span></dt><dd><p>
      Causes the AppArmor module to rescan the profiles in
      <code class="filename">/etc/apparmor.d</code> without unconfining running
      processes. Freshly created profiles are enforced and recently deleted
      ones are removed from the <code class="filename">/etc/apparmor.d</code>
      directory.
     </p></dd><dt><span class="term"><span class="command"><strong>rcapparmor kill</strong></span>
    </span></dt><dd><p>
      Unconditionally removes the AppArmor module from the kernel. However,
      unloading modules from the Linux kernel is unsafe. This command is
      provided only for debugging and emergencies (when the module might
      need to be removed).
     </p><div class="warning"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Warning"><tr class="head"><td width="32"><img alt="[Warning]" src="admon/warning.png"></td><th align="left"></th></tr><tr><td colspan="2" align="left" valign="top"><p>
       AppArmor is a powerful access control system and it is possible to lock
       yourself out of your own machine to the point where you must boot the
       machine from a rescue medium (such as the first medium of
       <span>openSUSE</span>)
       to regain control.
      </p><p>
       To prevent such a problem, always ensure that you have a running,
       unconfined, <code class="systemitem">root</code> login on the machine being configured when you
       restart the AppArmor module. If you damage your system to the point where
       logins are no longer possible (for example, by breaking the profile
       associated with the SSH daemon), you can repair the damage using your
       running <code class="systemitem">root</code> prompt then restarting the AppArmor module.
      </p></td></tr></table></div></dd></dl></div></div><div class="sect1" title="23.2. Building AppArmor Profiles"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.commandline.build"></a>23.2. Building AppArmor Profiles<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.commandline.build">¶</a></span></h2></div></div></div><p>
   The AppArmor module profile definitions are stored in the
   <code class="filename">/etc/apparmor.d</code> directory as plain text files. For a
   detailed description of the syntax of these files, refer 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>.
  </p><p>
   All files in the <code class="filename">/etc/apparmor.d</code> directory are
   interpreted as profiles and are loaded as such. Renaming files in that
   directory is not an effective way of preventing profiles from being
   loaded. You must remove profiles from this directory to prevent them from
   being read and evaluated effectively.
  </p><p>
   You can use a text editor, such as vim, to access and make changes to
   these profiles. The following options contain detailed steps for building
   profiles:
  </p><div class="variablelist"><dl><dt><span class="term">Adding or Creating AppArmor Profiles</span></dt><dd><p>
      Refer to <a class="xref" href="cha.apparmor.commandline.html#sec.apparmor.commandline.add" title="23.3. Adding or Creating an AppArmor Profile">Section 23.3, &#8220;Adding or Creating an AppArmor Profile&#8221;</a>
     </p></dd><dt><span class="term">Editing AppArmor Profiles</span></dt><dd><p>
      Refer to <a class="xref" href="cha.apparmor.commandline.html#sec.apparmor.commandline.edit" title="23.4. Editing an AppArmor Profile">Section 23.4, &#8220;Editing an AppArmor Profile&#8221;</a>
     </p></dd><dt><span class="term">Deleting AppArmor Profiles</span></dt><dd><p>
      Refer to
      <a class="xref" href="cha.apparmor.commandline.html#sec.apparmor.commandline.del" title="23.5. Deleting an AppArmor Profile">Section 23.5, &#8220;Deleting an AppArmor Profile&#8221;</a>
     </p></dd></dl></div></div><div class="sect1" title="23.3. Adding or Creating an AppArmor Profile"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.commandline.add"></a>23.3. Adding or Creating an AppArmor Profile<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.commandline.add">¶</a></span></h2></div></div></div><p>
   To add or create an AppArmor profile for an application, you can use a
   systemic or stand-alone profiling method, depending on your needs. Learn
   more about these two approaches in
   <a class="xref" href="cha.apparmor.commandline.html#sec.apparmor.commandline.profiling" title="23.6. Two Methods of Profiling">Section 23.6, &#8220;Two Methods of Profiling&#8221;</a>.
  </p></div><div class="sect1" title="23.4. Editing an AppArmor Profile"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.commandline.edit"></a>23.4. Editing an AppArmor Profile<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.commandline.edit">¶</a></span></h2></div></div></div><p>
   The following steps describe the procedure for editing an AppArmor profile:
  </p><div class="procedure"><ol class="procedure" type="1"><li><p>
     If you are not currently logged in as <code class="systemitem">root</code>, enter
     <span class="command"><strong>su</strong></span> in a terminal window.
    </p></li><li><p>
     Enter the <code class="systemitem">root</code> password when prompted.
    </p></li><li><p>
     Go to the profile directory with <span class="command"><strong>cd
     /etc/apparmor.d/</strong></span>.
    </p></li><li><p>
     Enter <span class="command"><strong>ls</strong></span> to view all profiles currently installed.
    </p></li><li><p>
     Open the profile to edit in a text editor, such as vim.
    </p></li><li><p>
     Make the necessary, changes then save the profile.
    </p></li><li><p>
     Restart AppArmor by entering <span class="command"><strong>rcapparmor restart</strong></span> in a
     terminal window.
    </p></li></ol></div></div><div class="sect1" title="23.5. Deleting an AppArmor Profile"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.commandline.del"></a>23.5. Deleting an AppArmor Profile<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.commandline.del">¶</a></span></h2></div></div></div><p>
   The following steps describe the procedure for deleting an AppArmor profile.
  </p><div class="procedure"><ol class="procedure" type="1"><li><p>
     If you are not currently logged in as <code class="systemitem">root</code>, enter
     <span class="command"><strong>su</strong></span> in a terminal window.
    </p></li><li><p>
     Enter the <code class="systemitem">root</code> password when prompted.
    </p></li><li><p>
     Go to the AppArmor directory with <span class="command"><strong>cd /etc/apparmor.d/</strong></span>.
    </p></li><li><p>
     Enter <span class="command"><strong>ls</strong></span> to view all the AppArmor profiles that are
     currently installed.
    </p></li><li><p>
     Delete the profile with <span class="command"><strong>rm
     <em class="replaceable"><code>profilename</code></em></strong></span>.
    </p></li><li><p>
     Restart AppArmor by entering <span class="command"><strong>rcapparmor restart</strong></span> in a
     terminal window.
    </p></li></ol></div></div><div class="sect1" title="23.6. Two Methods of Profiling"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.commandline.profiling"></a>23.6. Two Methods of Profiling<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.commandline.profiling">¶</a></span></h2></div></div></div><p>
   Given the syntax for AppArmor profiles in
   <a class="xref" href="cha.apparmor.profiles.html" title="Chapter 20. Profile Components and Syntax">Chapter 20, <i>Profile Components and Syntax</i></a>, you
   could create profiles without using the tools. However, the effort
   involved would be substantial. To avoid such a hassle, use the AppArmor tools
   to automate the creation and refinement of profiles.
  </p><p>
   There are two ways to approach AppArmor profile creation. Tools are available
   for both methods.
  </p><div class="variablelist"><dl><dt><span class="term">Stand-Alone Profiling</span></dt><dd><p>
      A method suitable for profiling small applications that have a finite
      run time, such as user client applications like mail clients. For more
      information, refer to
      <a class="xref" href="cha.apparmor.commandline.html#sec.apparmor.commandline.profiling.stand-alone" title="23.6.1. Stand-Alone Profiling">Section 23.6.1, &#8220;Stand-Alone Profiling&#8221;</a>.
     </p></dd><dt><span class="term">Systemic Profiling</span></dt><dd><p>
      A method suitable for profiling large numbers of programs all at once
      and for profiling applications that may run for days, weeks, or
      continuously across reboots, such as network server applications like
      Web servers and mail servers. For more information, refer to
      <a class="xref" href="cha.apparmor.commandline.html#sec.apparmor.commandline.profiling.systemic" title="23.6.2. Systemic Profiling">Section 23.6.2, &#8220;Systemic Profiling&#8221;</a>.
     </p></dd></dl></div><p>
   Automated profile development becomes more manageable with the AppArmor
   tools:
  </p><div class="procedure"><ol class="procedure" type="1"><li><p>
     Decide which profiling method suits your needs.
    </p></li><li><p>
     Perform a static analysis. Run either aa-genprof or aa-autodep,
     depending on the profiling method chosen.
    </p></li><li><p>
     Enable dynamic learning. Activate learning mode for all profiled
     programs.
    </p></li></ol></div><div class="sect2" title="23.6.1. Stand-Alone Profiling"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.commandline.profiling.stand-alone"></a>23.6.1. Stand-Alone Profiling<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.commandline.profiling.stand-alone">¶</a></span></h3></div></div></div><p>
    Stand-alone profile generation and improvement is managed by a program
    called aa-genprof. This method is easy because aa-genprof takes care of
    everything, but is limited because it requires aa-genprof to run for the
    entire duration of the test run of your program (you cannot reboot the
    machine while you are still developing your profile).
   </p><p>
    To use aa-genprof for the stand-alone method of profiling, refer to
    <a class="xref" href="cha.apparmor.commandline.html#sec.apparmor.commandline.profiling.summary.genprof" title="23.6.3.4. aa-genprof&#8212;Generating Profiles">Section 23.6.3.4, &#8220;aa-genprof&#8212;Generating Profiles&#8221;</a>.
   </p></div><div class="sect2" title="23.6.2. Systemic Profiling"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.commandline.profiling.systemic"></a>23.6.2. Systemic Profiling<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.commandline.profiling.systemic">¶</a></span></h3></div></div></div><p>
    This method is called <span class="emphasis"><em>systemic profiling</em></span> because it
    updates all of the profiles on the system at once, rather than focusing
    on the one or few targeted by aa-genprof or stand-alone profiling. With
    systemic profiling, profile construction and improvement are somewhat
    less automated, but more flexible. This method is suitable for profiling
    long-running applications whose behavior continues after rebooting, or a
    large number of programs all at once.
   </p><p>
    Build an AppArmor profile for a group of applications as follows:
   </p><div class="procedure"><ol class="procedure" type="1"><li><p>
      Create profiles for the individual programs that make up your
      application.
     </p><p>
      Although this approach is systemic, AppArmor only monitors those programs
      with profiles and their children. To get AppArmor to consider a program,
      you must at least have aa-autodep create an approximate profile for
      it. To create this approximate profile, refer to
      <a class="xref" href="cha.apparmor.commandline.html#sec.apparmor.commandline.profiling.summary.autodep" title="23.6.3.1. aa-autodep&#8212;Creating Approximate Profiles">Section 23.6.3.1, &#8220;aa-autodep&#8212;Creating Approximate Profiles&#8221;</a>.
     </p></li><li><p>
      Put relevant profiles into learning or complain mode.
     </p><p>
      Activate learning or complain mode for all profiled programs by
      entering <span class="command"><strong>aa-complain /etc/apparmor.d/*</strong></span> in a
      terminal window while logged in as <code class="systemitem">root</code>. This functionality is
      also available through the YaST Profile Mode module, described in
      <a class="xref" href="cha.apparmor.yast.html#sec.apparmor.yast.manage.profmodes" title="22.6.2. Changing the Mode of Individual Profiles">Section 22.6.2, &#8220;Changing the Mode of Individual Profiles&#8221;</a>.
     </p><p>
      When in learning mode, access requests are not blocked, even if the
      profile dictates that they should be. This enables you to run through
      several tests (as shown in
      <a class="xref" href="cha.apparmor.commandline.html#st.apparmor.commandline.profiling.systemic.exec" title="Step 3">Step 3</a>) and
      learn the access needs of the program so it runs properly. With this
      information, you can decide how secure to make the profile.
     </p><p>
      Refer to
      <a class="xref" href="cha.apparmor.commandline.html#sec.apparmor.commandline.profiling.summary.complain" title="23.6.3.2. aa-complain&#8212;Entering Complain or Learning Mode">Section 23.6.3.2, &#8220;aa-complain&#8212;Entering Complain or Learning Mode&#8221;</a>
      for more detailed instructions for using learning or complain mode.
     </p></li><li id="st.apparmor.commandline.profiling.systemic.exec"><p>
      Exercise your application.
     </p><p>
      Run your application and exercise its functionality. How much to
      exercise the program is up to you, but you need the program to access
      each file representing its access needs. Because the execution is not
      being supervised by aa-genprof, this step can go on for days or weeks
      and can span complete system reboots.
     </p></li><li id="st.apparmor.commandline.profiling.systemic.log"><p>
      Analyze the log.
     </p><p>
      In systemic profiling, run aa-logprof directly instead of letting
      aa-genprof run it (as in stand-alone profiling). The general form of
      aa-logprof is:
     </p><pre class="screen">aa-logprof [ -d <em class="replaceable"><code>/path/to/profiles</code></em> ] [ -f <em class="replaceable"><code>/path/to/logfile</code></em> ]</pre><p>
      Refer to
      <a class="xref" href="cha.apparmor.commandline.html#sec.apparmor.commandline.profiling.summary.logprof" title="23.6.3.5. aa-logprof&#8212;Scanning the System Log">Section 23.6.3.5, &#8220;aa-logprof&#8212;Scanning the System Log&#8221;</a>
      for more information about using aa-logprof.
     </p></li><li><p>
      Repeat
      <a class="xref" href="cha.apparmor.commandline.html#st.apparmor.commandline.profiling.systemic.exec" title="Step 3">Step 3</a> and
      <a class="xref" href="cha.apparmor.commandline.html#st.apparmor.commandline.profiling.systemic.log" title="Step 4">Step 4</a>.
     </p><p>
      This generates optimum profiles. An iterative approach captures
      smaller data sets that can be trained and reloaded into the policy
      engine. Subsequent iterations generate fewer messages and run faster.
     </p></li><li><p>
      Edit the profiles.
     </p><p>
      You might want to review the profiles that have been generated. You
      can open and edit the profiles in
      <code class="filename">/etc/apparmor.d/</code> using vim.


     </p></li><li><p>
      Return to enforce mode.
     </p><p>
      This is when the system goes back to enforcing the rules of the
      profiles, not just logging information. This can be done manually by
      removing the <code class="literal">flags=(complain)</code> text from the
      profiles or automatically by using the <span class="command"><strong>aa-enforce</strong></span>
      command, which works identically to the <span class="command"><strong>aa-complain</strong></span>
      command, except it sets the profiles to enforce mode. This
      functionality is also available through the YaST Profile Mode
      module, described in
      <a class="xref" href="cha.apparmor.yast.html#sec.apparmor.yast.manage.profmodes" title="22.6.2. Changing the Mode of Individual Profiles">Section 22.6.2, &#8220;Changing the Mode of Individual Profiles&#8221;</a>.
     </p><p>
      To ensure that all profiles are taken out of complain mode and put
      into enforce mode, enter <span class="command"><strong>aa-enforce
      /etc/apparmor.d/*</strong></span>.
     </p></li><li><p>
      Rescan all profiles.
     </p><p>
      To have AppArmor rescan all of the profiles and change the enforcement
      mode in the kernel, enter <span class="command"><strong>rcapparmor restart</strong></span>.
     </p></li></ol></div></div><div class="sect2" title="23.6.3. Summary of Profiling Tools"><div class="titlepage"><div><div><h3 class="title"><a name="sec.apparmor.commandline.profiling.summary"></a>23.6.3. Summary of Profiling Tools<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.commandline.profiling.summary">¶</a></span></h3></div></div></div><p>
    All of the AppArmor profiling utilities are provided by the
    <code class="systemitem">apparmor-utils</code> RPM package and are stored in
    <code class="filename">/usr/sbin</code>. Each tool has a different purpose.
   </p><div class="sect3" title="23.6.3.1. aa-autodep&#8212;Creating Approximate Profiles"><div class="titlepage"><div><div><h4 class="title"><a name="sec.apparmor.commandline.profiling.summary.autodep"></a>23.6.3.1. aa-autodep&#8212;Creating Approximate Profiles<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.commandline.profiling.summary.autodep">¶</a></span></h4></div></div></div><p>
     This creates an approximate profile for the program or application
     selected. You can generate approximate profiles for binary executables
     and interpreted script programs. The resulting profile is called
     <span class="quote">&#8220;<span class="quote">approximate</span>&#8221;</span> because it does not necessarily contain all
     of the profile entries that the program needs to be properly confined
     by AppArmor. The minimum aa-autodep approximate profile has, at minimum, a
     base include directive, which contains basic profile entries needed by
     most programs. For certain types of programs, aa-autodep generates a
     more expanded profile. The profile is generated by recursively calling
     <span class="command"><strong>ldd(1)</strong></span> on the executables listed on the command
     line.
    </p><p>
     To generate an approximate profile, use the aa-autodep program. The
     program argument can be either the simple name of the program, which
     aa-autodep finds by searching your shell's path variable, or it can be
     a fully qualified path. The program itself can be of any type (ELF
     binary, shell script, Perl script, etc.). aa-autodep generates an
     approximate profile to improve through the dynamic profiling that
     follows.
    </p><p>
     The resulting approximate profile is written to the
     <code class="filename">/etc/apparmor.d</code> directory using the AppArmor profile
     naming convention of naming the profile after the absolute path of the
     program, replacing the forward slash (<code class="literal">/</code>) characters
     in the path with period (<code class="literal">.</code>) characters. The general
     form of aa-autodep is to enter the following in a terminal window when
     logged in as <code class="systemitem">root</code>:
    </p><pre class="screen">aa-autodep [ -d <em class="replaceable"><code>/path/to/profiles</code></em> ] [<em class="replaceable"><code>program1</code></em> <em class="replaceable"><code>program2</code></em>...]</pre><p>
     If you do not enter the program name or names, you are prompted for
     them. <em class="replaceable"><code>/path/to/profiles</code></em> overrides the
     default location of <code class="filename">/etc/apparmor.d</code>, should you
     keep profiles in a location other than the default.
    </p><p>
     To begin profiling, you must create profiles for each main executable
     service that is part of your application (anything that might start
     without being a child of another program that already has a profile).
     Finding all such programs depends on the application in question. Here
     are several strategies for finding such programs:
    </p><div class="variablelist"><dl><dt><span class="term">Directories</span></dt><dd><p>
        If all the programs to profile are in one directory and there are no
        other programs in that directory, the simple command
        <span class="command"><strong>aa-autodep
        <em class="replaceable"><code>/path/to/your/programs/*</code></em></strong></span>
        creates basic profiles for all programs in that directory.
       </p></dd><dt><span class="term">ps command</span></dt><dd><p>
        You can run your application and use the standard Linux
        <span class="command"><strong>ps</strong></span> command to find all processes running. Then
        manually hunt down the location of these programs and run the
        <span class="command"><strong>aa-autodep</strong></span> for each one. If the programs are in
        your path, aa-autodep finds them for you. If they are not in your
        path, the standard Linux command <span class="command"><strong>find</strong></span> might be
        helpful in finding your programs. Execute <span class="command"><strong>find / -name
        '<em class="replaceable"><code>my_application</code></em>' -print</strong></span> to
        determine an application's path
        (<em class="replaceable"><code>my_application</code></em> being an example
        application). You may use wild cards if appropriate.
       </p></dd></dl></div></div><div class="sect3" title="23.6.3.2. aa-complain&#8212;Entering Complain or Learning Mode"><div class="titlepage"><div><div><h4 class="title"><a name="sec.apparmor.commandline.profiling.summary.complain"></a>23.6.3.2. aa-complain&#8212;Entering Complain or Learning Mode<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.commandline.profiling.summary.complain">¶</a></span></h4></div></div></div><p>
     The complain or learning mode tool (aa-complain) detects violations of
     AppArmor profile rules, such as the profiled program accessing files not
     permitted by the profile. 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 to
     transform log events into improved profiles.
    </p><p>
     Manually activating complain mode (using the command line) adds a flag
     to the top of the profile so that <code class="literal">/bin/foo</code> becomes
     <code class="literal">/bin/foo flags=(complain)</code>. To use complain mode,
     open a terminal window and enter one of the following lines as
     <code class="systemitem">root</code>:
    </p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
       If the example program (<em class="replaceable"><code>program1</code></em>) is in
       your path, use:
      </p><pre class="screen">aa-complain [<em class="replaceable"><code>program1</code></em> <em class="replaceable"><code>program2</code></em> ...]</pre></li><li class="listitem" style="list-style-type: disc"><p>
       If the program is not in your path, specify the entire path as
       follows:
      </p><pre class="screen">aa-complain /sbin/<em class="replaceable"><code>program1</code></em>
</pre></li><li class="listitem" style="list-style-type: disc"><p>
       If the profiles are not in <code class="filename">/etc/apparmor.d</code>, use
       the following to override the default location:
      </p><pre class="screen">aa-complain <em class="replaceable"><code>/path/to/profiles/</code></em> <em class="replaceable"><code>program1</code></em>
     </pre></li><li class="listitem" style="list-style-type: disc"><p>
       Specify the profile for <em class="replaceable"><code>program1</code></em> as
       follows:
      </p><pre class="screen">aa-complain /etc/apparmor.d/sbin.<em class="replaceable"><code>program1</code></em></pre></li></ul></div><p>
     Each of the above commands activates the complain mode for the profiles
     or programs listed. If the program name does not include its entire
     path, aa-complain searches <code class="envar">$PATH</code> for the program. For
     instance, <span class="command"><strong>aa-complain /usr/sbin/*</strong></span> finds profiles
     associated with all of the programs in <code class="filename">/usr/sbin</code>
     and puts them into complain mode. <span class="command"><strong>aa-complain
     /etc/apparmor.d/*</strong></span> puts all of the profiles in
     <code class="filename">/etc/apparmor.d</code> into complain mode.
    </p><div class="tip"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Tip: Toggling Profile Mode with YaST"><tr class="head"><td width="32"><img alt="[Tip]" src="admon/tip.png"></td><th align="left">Toggling Profile Mode with YaST</th></tr><tr><td colspan="2" align="left" valign="top"><p>
      YaST offers a graphical front-end for toggling complain and enforce
      mode. See <a class="xref" href="cha.apparmor.yast.html#sec.apparmor.yast.manage.profmodes" title="22.6.2. Changing the Mode of Individual Profiles">Section 22.6.2, &#8220;Changing the Mode of Individual Profiles&#8221;</a> for
      information.
     </p></td></tr></table></div></div><div class="sect3" title="23.6.3.3. aa-enforce&#8212;Entering Enforce Mode"><div class="titlepage"><div><div><h4 class="title"><a name="sec.apparmor.commandline.profiling.summary.enforce"></a>23.6.3.3. aa-enforce&#8212;Entering Enforce Mode<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.commandline.profiling.summary.enforce">¶</a></span></h4></div></div></div><p>
     The enforce mode detects violations of AppArmor profile rules, such as the
     profiled program accessing files not permitted by the profile. 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><p>
     Manually activating enforce mode (using the command line) adds a flag
     to the top of the profile so that <code class="literal">/bin/foo</code> becomes
     <code class="literal">/bin/foo flags=(enforce)</code>. To use enforce mode, open
     a terminal window and enter one of the following lines as <code class="systemitem">root</code>.
    </p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
       If the example program (<em class="replaceable"><code>program1</code></em>) is in
       your path, use:
      </p><pre class="screen">aa-enforce [<em class="replaceable"><code>program1</code></em> <em class="replaceable"><code>program2</code></em> ...]</pre></li><li class="listitem" style="list-style-type: disc"><p>
       If the program is not in your path, specify the entire path, as
       follows:
      </p><pre class="screen">aa-enforce /sbin/<em class="replaceable"><code>program1</code></em></pre></li><li class="listitem" style="list-style-type: disc"><p>
       If the profiles are not in
       <em class="replaceable"><code>/etc/apparmor.d</code></em>, use the following to
       override the default location:
      </p><pre class="screen">aa-enforce <em class="replaceable"><code>/path/to/profiles/program1</code></em></pre></li><li class="listitem" style="list-style-type: disc"><p>
       Specify the profile for <em class="replaceable"><code>program1</code></em> as
       follows:
      </p><pre class="screen">aa-enforce /etc/apparmor.d/sbin.<em class="replaceable"><code>program1</code></em></pre></li></ul></div><p>
     Each of the above commands activates the enforce mode for the profiles
     and programs listed.
    </p><p>
     If you do not enter the program or profile names, you are prompted to
     enter one. <em class="replaceable"><code>/path/to/profiles</code></em> overrides the
     default location of <code class="filename">/etc/apparmor.d</code>.
    </p><p>
     The argument can be either a list of programs or a list of profiles. If
     the program name does not include its entire path, aa-enforce searches
     <code class="envar">$PATH</code> for the program.
    </p><div class="tip"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Tip: Toggling Profile Mode with YaST"><tr class="head"><td width="32"><img alt="[Tip]" src="admon/tip.png"></td><th align="left">Toggling Profile Mode with YaST</th></tr><tr><td colspan="2" align="left" valign="top"><p>
      YaST offers a graphical front-end for toggling complain and enforce
      mode. See <a class="xref" href="cha.apparmor.yast.html#sec.apparmor.yast.manage.profmodes" title="22.6.2. Changing the Mode of Individual Profiles">Section 22.6.2, &#8220;Changing the Mode of Individual Profiles&#8221;</a> for
      information.
     </p></td></tr></table></div></div><div class="sect3" title="23.6.3.4. aa-genprof&#8212;Generating Profiles"><div class="titlepage"><div><div><h4 class="title"><a name="sec.apparmor.commandline.profiling.summary.genprof"></a>23.6.3.4. aa-genprof&#8212;Generating Profiles<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.commandline.profiling.summary.genprof">¶</a></span></h4></div></div></div><p>
     aa-genprof is AppArmor's profile generating utility. It runs aa-autodep on
     the specified program, creating an approximate profile (if a profile
     does not already exist for it), sets it to complain mode, reloads it
     into AppArmor, marks the log, and prompts the user to execute the program
     and exercise its functionality. Its syntax is as follows:
    </p><pre class="screen">aa-genprof [ -d <em class="replaceable"><code>/path/to/profiles</code></em> ]  <em class="replaceable"><code>program</code></em></pre><p>
     To create a profile for the the Apache Web server program
     httpd2-prefork, do the following as <code class="systemitem">root</code>:
    </p><div class="procedure"><ol class="procedure" type="1"><li><p>
       Enter <span class="command"><strong>rcapache2 stop</strong></span>.
      </p></li><li><p>
       Next, enter <span class="command"><strong>aa-genprof httpd2-prefork</strong></span>.
      </p><p>
       Now aa-genprof does the following:
      </p><div class="orderedlist"><ol class="orderedlist" type="1"><li><p>
         Resolves the full path of httpd2-prefork using your shell's path
         variables. You can also specify a full path. On
         <span>openSUSE</span>,
         the default full path is
         <code class="filename">/usr/sbin/httpd2-prefork</code>.
        </p></li><li><p>
         Checks to see if there is an existing profile for httpd2-prefork.
         If there is one, it updates it. If not, it creates one using the
         aa-autodep as described in
         <a class="xref" href="cha.apparmor.commandline.html#sec.apparmor.commandline.profiling.summary" title="23.6.3. Summary of Profiling Tools">Section 23.6.3, &#8220;Summary of Profiling Tools&#8221;</a>.
        </p></li><li><p>
         Puts the profile for this program into learning or complain mode so
         that profile violations are logged, but are permitted to proceed. A
         log event looks like this (see
         <code class="filename">/var/log/audit/audit.log</code>):
        </p><pre class="screen">type=APPARMOR_ALLOWED msg=audit(1189682639.184:20816): operation="file_mmap" requested_mask="::r" denied_mask="::r" fsuid=30 name="/srv/www/htdocs/index.html" pid=27471 profile="null-complain-profile"
</pre><p>
         If you are not running the audit daemon, the AppArmor events are logged
         to <code class="filename">/var/log/messages</code>:
        </p><pre class="screen">Sep 13 13:20:30 K23 kernel: audit(1189682430.672:20810): operation="file_mmap" requested_mask="::r" denied_mask="::r" fsuid=30 name="/srv/www/htdocs/phpsysinfo/templates/bulix/form.tpl" pid=30405 profile="/usr/sbin/httpd2-prefork///phpsysinfo/"</pre><p>
         They also can be viewed using the <span class="command"><strong>dmesg</strong></span> command:
        </p><pre class="screen">audit(1189682430.672:20810): operation="file_mmap" requested_mask="::r" denied_mask="::r" fsuid=30 name="/srv/www/htdocs/phpsysinfo/templates/bulix/form.tpl" pid=30405 profile="/usr/sbin/httpd2-prefork///phpsysinfo/"</pre></li><li><p>
         Marks the log with a beginning marker of log events to consider.
         For example:
        </p><pre class="screen">
Sep 13 17:48:52 figwit root: GenProf: e2ff78636296f16d0b5301209a04430d</pre></li></ol></div></li><li><p>
       When prompted by the tool, run the application to profile in another
       terminal window and perform as many of the application functions as
       possible. Thus, the learning mode can log the files and directories
       to which the program requires access in order to function properly.
       For example, in a new terminal window, enter <span class="command"><strong>rcapache2
       start</strong></span>.
      </p></li><li><p>
       Select from the following options that are available in the
       aa-logprof terminal window after you have executed the program
       function:
      </p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
         <span class="keycap">S</span> runs aa-logprof on the system log from where it
         was marked when aa-genprof was started and reloads the profile. If
         system events exist in the log, AppArmor parses the learning mode log
         files. This generates a series of questions that you must answer to
         guide aa-genprof in generating the security profile.
        </p></li><li class="listitem" style="list-style-type: disc"><p>
         <span class="keycap">F</span> exits the tool and returns to the main menu.
        </p></li></ul></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>
        If requests to add hats appear, proceed 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></li><li><p>
       Answer two types of questions:
      </p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
         A resource is requested by a profiled program that is not in the
         profile (see
         <a class="xref" href="cha.apparmor.commandline.html#ex.apparmor.commandline.profiling.summary.genprof.learn" title="Example 23.1. Learning Mode Exception: Controlling Access to Specific Resources">Example 23.1, &#8220;Learning Mode Exception: Controlling Access to Specific Resources&#8221;</a>).
        </p></li><li class="listitem" style="list-style-type: disc"><p>
         A program is executed by the profiled program and the security
         domain transition has not been defined (see
         <a class="xref" href="cha.apparmor.commandline.html#ex.apparmor.commandline.profiling.summary.genprof.perms" title="Example 23.2. Learning Mode Exception: Defining Execute Permissions for an Entry">Example 23.2, &#8220;Learning Mode Exception: Defining Execute Permissions for an Entry&#8221;</a>).
        </p></li></ul></div><p>
       Each of these categories results in a series of questions that you
       must answer to add the resource or program to the profile.
       <a class="xref" href="cha.apparmor.commandline.html#ex.apparmor.commandline.profiling.summary.genprof.learn" title="Example 23.1. Learning Mode Exception: Controlling Access to Specific Resources">Example 23.1, &#8220;Learning Mode Exception: Controlling Access to Specific Resources&#8221;</a>
       and
       <a class="xref" href="cha.apparmor.commandline.html#ex.apparmor.commandline.profiling.summary.genprof.perms" title="Example 23.2. Learning Mode Exception: Defining Execute Permissions for an Entry">Example 23.2, &#8220;Learning Mode Exception: Defining Execute Permissions for an Entry&#8221;</a>
       provide examples of each one. Subsequent steps describe your options
       in answering these questions.
      </p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
         Dealing with execute accesses is complex. You must decide how to
         proceed with this entry regarding which execute permission type to
         grant to this entry:
        </p><div class="example"><a name="ex.apparmor.commandline.profiling.summary.genprof.learn"></a><p class="title"><b>Example 23.1. Learning Mode Exception: Controlling Access to Specific Resources</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#ex.apparmor.commandline.profiling.summary.genprof.learn">¶</a></span></p><div class="example-contents"><pre class="screen">Reading log entries from /var/log/audit/audit.log.
Updating AppArmor profiles in /etc/apparmor.d.

Profile:  /usr/sbin/xinetd
Program:  xinetd
Execute:  /usr/lib/cups/daemon/cups-lpd
Severity: unknown

[(I)nherit] / (P)rofile / (U)nconfined / (D)eny / Abo(r)t / (F)inish
</pre></div></div><br class="example-break"><div class="variablelist"><dl><dt><span class="term">Inherit (ix)</span></dt><dd><p>
            The child inherits the parent's profile, running with the same
            access controls as the parent. 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. This mode is often used when
            the child program is a <span class="emphasis"><em>helper application</em></span>,
            such as the <span class="command"><strong>/usr/bin/mail</strong></span> client using
            <span class="command"><strong>less</strong></span> as a pager or the Mozilla* Web browser
            using Adobe Acrobat* to display PDF files.
           </p></dd><dt><span class="term">Profile (px)</span></dt><dd><p>
            The child runs using its own profile, which must be loaded into
            the kernel. If the profile is not present, attempts to execute
            the child fail with permission denied. This is most useful if
            the parent program is invoking a global service, such as DNS
            lookups or sending mail with your system's MTA.
           </p><p>
            Choose the <span class="guimenu">profile with clean exec</span> (Px)
            option to scrub the environment of environment variables that
            could modify execution behavior when passed to the child
            process.
           </p></dd><dt><span class="term">Unconfined (ux)</span></dt><dd><p>
            The child runs completely unconfined without any AppArmor profile
            applied to the executed resource.
           </p><p>
            Choose the <span class="guimenu">unconfined with clean exec</span> (Ux)
            option to scrub the environment of environment variables that
            could modify execution behavior when passed to the child
            process. This option introduces a security vulnerability that
            could be used to exploit AppArmor. Only use it as a last resort.
           </p></dd><dt><span class="term">mmap (m)</span></dt><dd><p>
            This permission denotes that the program running under the
            profile can access the resource using the mmap system call with
            the flag <code class="envar">PROT_EXEC</code>. This means that the data
            mapped in it can be executed. You are prompted to include this
            permission if it is requested during a profiling run.
           </p></dd><dt><span class="term">Deny</span></dt><dd><p>
            Prevents the program from accessing the specified directory path
            entries. AppArmor then continues to the next event.
           </p></dd><dt><span class="term">Abort</span></dt><dd><p>
            Aborts aa-logprof, losing all rule changes entered so far and
            leaving all profiles unmodified.
           </p></dd><dt><span class="term">Finish</span></dt><dd><p>
            Closes aa-logprof, saving all rule changes entered so far and
            modifying all profiles.
           </p></dd></dl></div></li><li class="listitem" style="list-style-type: disc"><p>
         <a class="xref" href="cha.apparmor.commandline.html#ex.apparmor.commandline.profiling.summary.genprof.perms" title="Example 23.2. Learning Mode Exception: Defining Execute Permissions for an Entry">Example 23.2, &#8220;Learning Mode Exception: Defining Execute Permissions for an Entry&#8221;</a>
         shows AppArmor suggesting directory path entries that have been
         accessed by the application being profiled. It might also require
         you to define execute permissions for entries.
        </p><div class="example"><a name="ex.apparmor.commandline.profiling.summary.genprof.perms"></a><p class="title"><b>Example 23.2. Learning Mode Exception: Defining Execute Permissions for an Entry</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#ex.apparmor.commandline.profiling.summary.genprof.perms">¶</a></span></p><div class="example-contents"><pre class="screen">Adding /bin/ps ix to profile.

Profile:  /usr/sbin/xinetd
Path:     /etc/hosts.allow
New Mode: r

 [1 - /etc/hosts.allow]

[(A)llow] / (D)eny / (N)ew / (G)lob / Glob w/(E)xt / Abo(r)t / (F)inish
</pre></div></div><br class="example-break"><p>
         AppArmor provides one or more paths or includes. By entering the option
         number, select the desired options then proceed to the next step.
        </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>
          All of these options are not always presented in the AppArmor menu.
         </p></td></tr></table></div><div class="variablelist"><dl><dt><span class="term"><code class="literal">#include</code>
          </span></dt><dd><p>
            This is the section of an AppArmor profile that refers to an include
            file, which procures 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. It is good practice
            to select includes when suggested.
           </p></dd><dt><span class="term">Globbed Version</span></dt><dd><p>
            This is accessed by selecting <span class="guimenu">Glob</span> as
            described in the next step. For information about globbing
            syntax, refer to <a class="xref" href="cha.apparmor.profiles.html#sec.apparmor.profiles.glob" title="20.6. Paths and Globbing">Section 20.6, &#8220;Paths and Globbing&#8221;</a>.
           </p></dd><dt><span class="term">Actual Path</span></dt><dd><p>
            This is the literal path to which the program needs access so
            that it can run properly.
           </p></dd></dl></div><p>
         After you select the path or include, process it as an entry into
         the AppArmor profile by selecting <span class="guimenu">Allow</span> or
         <span class="guimenu">Deny</span>. If you are not satisfied with the
         directory path entry as it is displayed, you can also
         <span class="guimenu">Glob</span> it.
        </p><p>
         The following options are available to process the learning mode
         entries and build the profile:
        </p><div class="variablelist"><dl><dt><span class="term">Select <span class="keycap">Enter</span>
          </span></dt><dd><p>
            Allows access to the selected directory path.
           </p></dd><dt><span class="term">Allow</span></dt><dd><p>
            Allows access to the specified directory path entries. AppArmor
            suggests file permission access. For more information, refer to
            <a class="xref" href="cha.apparmor.profiles.html#sec.apparmor.profiles.perm" title="20.7. File Permission Access Modes">Section 20.7, &#8220;File Permission Access Modes&#8221;</a>.
           </p></dd><dt><span class="term">Deny</span></dt><dd><p>
            Prevents the program from accessing the specified directory path
            entries. AppArmor then continues to the next event.
           </p></dd><dt><span class="term">New</span></dt><dd><p>
            Prompts you to enter your own rule for this event, allowing you
            to specify a regular expression. If the expression does not
            actually satisfy the event that prompted the question in the
            first place, AppArmor asks for confirmation and lets you reenter the
            expression.
           </p></dd><dt><span class="term">Glob</span></dt><dd><p>
            Select a specific path or create a general rule using wild cards
            that match a broader set of paths. To select any of the offered
            paths, enter the number that is printed in front of the path
            then decide how to proceed with the selected item.
           </p><p>
            For more information about globbing syntax, refer to
            <a class="xref" href="cha.apparmor.profiles.html#sec.apparmor.profiles.glob" title="20.6. Paths and Globbing">Section 20.6, &#8220;Paths and Globbing&#8221;</a>.
           </p></dd><dt><span class="term">Glob w/Ext</span></dt><dd><p>
            This modifies the original directory path while retaining the
            filename extension. For example,
            <code class="filename">/etc/apache2/file.ext</code> becomes
            <code class="filename">/etc/apache2/*.ext</code>, adding the wild card
            (asterisk) in place of the filename. This allows the program to
            access all files in the suggested directory that end with the
            <code class="literal">.ext</code> extension.
           </p></dd><dt><span class="term">Abort</span></dt><dd><p>
            Aborts aa-logprof, losing all rule changes entered so far and
            leaving all profiles unmodified.
           </p></dd><dt><span class="term">Finish</span></dt><dd><p>
            Closes aa-logprof, saving all rule changes entered so far and
            modifying all profiles.
           </p></dd></dl></div></li></ul></div></li><li><p>
       To view and edit your profile using vim, enter <span class="command"><strong>vim
       /etc/apparmor.d/<em class="replaceable"><code>profilename</code></em></strong></span> in a
       terminal window.

      </p></li><li><p>
       Restart AppArmor and reload the profile set including the newly created
       one using the <span class="command"><strong>rcapparmor <code class="option">restart</code></strong></span>
       command.
      </p></li></ol></div><p>
     Like the graphical front-end for building AppArmor profiles, the YaST Add
     Profile Wizard, aa-genprof also supports the use of the local profile
     repository under
     <code class="filename">/etc/apparmor/profiles/extras</code><span>
     and the remote AppArmor profile repository</span>.
    </p><p>
     To use a profile from the local repository, proceed as follows:
    </p><div class="procedure"><ol class="procedure" type="1"><li><p>
       Start aa-genprof as described above.
      </p><p>
       If aa-genprof finds an inactive local profile, the following lines
       appear on your terminal window:
      </p><pre class="screen">Profile: /usr/bin/opera

 [1 - Inactive local profile for /usr/bin/opera]

[(V)iew Profile] / (U)se Profile / (C)reate New Profile / Abo(r)t / (F)inish</pre></li><li><p>
       If you want to just use this profile, hit <span class="keycap">U</span>
       (<span class="guimenu">Use Profile</span>) and follow the profile generation
       procedure outlined above.
      </p><p>
       If you want to examine the profile before activating it, hit
       <span class="keycap">V</span> (<span class="guimenu">View Profile</span>).
      </p><p>
       If you want to ignore the existing profile, hit <span class="keycap">C</span>
       (<span class="guimenu">Create New Profile</span>) and follow the profile
       generation procedure outlined above to create the profile from
       scratch.
      </p></li><li><p>
       Leave aa-genprof by hitting <span class="keycap">F</span>
       (<span class="guimenu">Finish</span>) when you are done and save your changes.
      </p></li></ol></div><p>
     To use the remote AppArmor profile repository with aa-genprof, proceed as
     follows:
    </p><div class="procedure"><ol class="procedure" type="1"><li><p>
       Start aa-genprof as described above.
      </p><p>
       If aa-genprof detects a suitable profile on the repository server,
       the following lines appear on your terminal window:
      </p><pre class="screen">Repository: http://apparmor.opensuse.org/backend/api

Would you like to enable access to the profile repository?

(E)nable Repository / (D)isable Repository / Ask Me (L)ater
</pre></li><li><p>
       Hit <span class="keycap">E</span> (<span class="guimenu">Enable Repository</span>) to
       enable the repository.
      </p></li><li><p>
       Determine whether you want to aa-genprof to upload any profiles to
       the repository server:
      </p><pre class="screen">Would you like to upload newly created and changed profiles to
      the profile repository?

(Y)es / (N)o / Ask Me (L)ater
</pre><p>
       Hit <span class="keycap">Y</span> (<span class="guimenu">Yes</span>), if you want to
       enable profile upload or select <span class="keycap">N</span>
       (<span class="guimenu">No</span>), if you want aa-genprof to just pull profiles
       from the repository, but not to upload any.
      </p></li><li><p>
       Create a new user on the profile repository server to be able to
       upload profiles. Provide username and password.
      </p></li><li><p>
       Determine whether you want to use the profile downloaded from the
       server or whether you would just like to review it:
      </p><pre class="screen">Profile: /usr/bin/opera

 [1 - novell]

[(V)iew Profile] / (U)se Profile / (C)reate New Profile / Abo(r)t / (F)inish
</pre><p>
       If you want to just use this profile, hit <span class="keycap">U</span>
       (<span class="guimenu">Use Profile</span>) and follow the profile generation
       procedure outlined above.
      </p><p>
       If you want to examine the profile before activating it, hit
       <span class="keycap">V</span> (<span class="guimenu">View Profile</span>).
      </p><p>
       If you want to ignore the existing profile, hit <span class="keycap">C</span>
       (<span class="guimenu">Create New Profile</span>) and follow the profile
       generation procedure outlined above to create the profile from
       scratch.
      </p></li><li><p>
       Leave aa-genprof by hitting <span class="keycap">F</span>
       (<span class="guimenu">Finish</span>) when you are done and save the profile.
      </p><p>
       If you opted for uploading your profile, provide a short change log
       and push it to the repository.
      </p></li></ol></div></div><div class="sect3" title="23.6.3.5. aa-logprof&#8212;Scanning the System Log"><div class="titlepage"><div><div><h4 class="title"><a name="sec.apparmor.commandline.profiling.summary.logprof"></a>23.6.3.5. aa-logprof&#8212;Scanning the System Log<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.commandline.profiling.summary.logprof">¶</a></span></h4></div></div></div><p>
     aa-logprof is an interactive tool used to review the learning or
     complain-mode output found in the log entries in
     <code class="filename">/var/log/audit/audit.log</code> or
     <code class="filename">/var/log/messages</code> (if auditd is not running) and
     generate new entries in AppArmor security profiles.
    </p><p>
     When you run aa-logprof, it begins to scan the log files produced in
     learning or complain mode and, if there are new security events that
     are not covered by the existing profile set, it gives suggestions for
     modifying the profile. The learning or complain mode traces program
     behavior and enters it in the log. aa-logprof uses this information to
     observe program behavior.
    </p><p>
     If a confined program forks and executes another program, aa-logprof
     sees this and asks the user which execution mode should be used when
     launching the child process. The execution modes
     <span class="emphasis"><em>ix</em></span>, <span class="emphasis"><em>px</em></span>,
     <span class="emphasis"><em>Px</em></span>, <span class="emphasis"><em>ux</em></span>, and
     <span class="emphasis"><em>Ux</em></span> are options for starting the child process. If
     a separate profile exists for the child process, the default selection
     is <span class="emphasis"><em>px</em></span>. If one does not exist, the profile defaults
     to <span class="emphasis"><em>ix</em></span>. Child processes with separate profiles have
     aa-autodep run on them and are loaded into AppArmor, if it is running.
    </p><p>
     When aa-logprof exits, profiles are updated with the changes. If the
     AppArmor module is running, the updated profiles are reloaded and, if any
     processes that generated security events are still running in the
     null-complain-profile, those processes are set to run under their
     proper profiles.
    </p><div class="tip"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Tip: Support for the External Profile Repository"><tr class="head"><td width="32"><img alt="[Tip]" src="admon/tip.png"></td><th align="left">Support for the External Profile Repository</th></tr><tr><td colspan="2" align="left" valign="top"><p>
      Similar to the aa-genprof, aa-logprof also supports profile exchange
      with the external repository server. For background information on the
      use of the external AppArmor profile repository, 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 details on how to
      configure access and access mode to the server, check the procedure
      described under
      <a class="xref" href="cha.apparmor.commandline.html#sec.apparmor.commandline.profiling.summary.genprof" title="23.6.3.4. aa-genprof&#8212;Generating Profiles">Section 23.6.3.4, &#8220;aa-genprof&#8212;Generating Profiles&#8221;</a>.
     </p></td></tr></table></div><p>
     To run aa-logprof, enter <span class="command"><strong>aa-logprof</strong></span> into a terminal
     window while logged in as <code class="systemitem">root</code>. The following options can be used
     for aa-logprof:
    </p><div class="variablelist"><dl><dt><span class="term"><span class="command"><strong>aa-logprof -d <em class="replaceable"><code>/path/to/profile/directory/</code></em></strong></span>
      </span></dt><dd><p>
        Specifies the full path to the location of the profiles if the
        profiles are not located in the standard directory,
        <code class="filename">/etc/apparmor.d/</code>.
       </p></dd><dt><span class="term"><span class="command"><strong>aa-logprof -f <em class="replaceable"><code>/path/to/logfile/</code></em></strong></span>
      </span></dt><dd><p>
        Specifies the full path to the location of the log file if the log
        file is not located in the default directory,
        <code class="filename">/var/log/audit/audit.log</code> or
        <code class="filename">/var/log/messages</code> (if auditd is not running).
       </p></dd><dt><span class="term"><span class="command"><strong>aa-logprof -m "string marker in logfile"</strong></span>
      </span></dt><dd><p>
        Marks the starting point for aa-logprof to look in the system log.
        aa-logprof ignores all events in the system log before the specified
        mark. If the mark contains spaces, it must be surrounded by quotes
        to work correctly. For example:
       </p><pre class="screen">aa-logprof -m"17:04:21"</pre><p>
        or
       </p><pre class="screen">logprof -m e2ff78636296f16d0b5301209a04430d</pre></dd></dl></div><p>
     aa-logprof scans the log, asking you how to handle each logged event.
     Each question presents a numbered list of AppArmor rules that can be added
     by pressing the number of the item on the list.
    </p><p>
     By default, aa-logprof looks for profiles in
     <code class="filename">/etc/apparmor.d/</code> and scans the log in
     <code class="filename">/var/log/messages</code>. In many cases, running
     <span class="command"><strong>aa-logprof</strong></span> as <code class="systemitem">root</code> is enough to create the
     profile.
    </p><p>
     However, there might be times when you need to search archived log
     files, such as if the program exercise period exceeds the log rotation
     window (when the log file is archived and a new log file is started).
     If this is the case, you can enter <span class="command"><strong>zcat -f `ls -1tr
     /var/log/messages*` | aa-logprof -f -</strong></span>.
    </p></div><div class="sect3" title="23.6.3.6. aa-logprof Example 1"><div class="titlepage"><div><div><h4 class="title"><a name="sec.apparmor.commandline.profiling.summary.logprof_ex1"></a>23.6.3.6. aa-logprof Example 1<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.commandline.profiling.summary.logprof_ex1">¶</a></span></h4></div></div></div><p>
     The following is an example of how aa-logprof addresses httpd2-prefork
     accessing the file <code class="filename">/etc/group</code>.
     <code class="literal">[]</code> indicates the default option.
    </p><p>
     In this example, the access to <span class="command"><strong>/etc/group</strong></span> is part of
     httpd2-prefork accessing name services. The appropriate response is
     <code class="literal">1</code>, which includes a predefined set of AppArmor rules.
     Selecting <code class="literal">1</code> to <code class="literal">#include</code> the name
     service package resolves all of the future questions pertaining to DNS
     lookups and also makes the profile less brittle in that any changes to
     DNS configuration and the associated name service profile package can
     be made just once, rather than needing to revise many profiles.
    </p><pre class="screen">
Profile:  /usr/sbin/httpd2-prefork
Path:     /etc/group
New Mode: r

[1 - #include &lt;abstractions/nameservice&gt;]
 2 - /etc/group
[(A)llow] / (D)eny / (N)ew / (G)lob / Glob w/(E)xt / Abo(r)t / (F)inish
</pre><p>
     Select one of the following responses:
    </p><div class="variablelist"><dl><dt><span class="term">Select <span class="keycap">Enter</span>
      </span></dt><dd><p>
        Triggers the default action, which is, in this example, allowing
        access to the specified directory path entry.
       </p></dd><dt><span class="term">Allow</span></dt><dd><p>
        Allows access to the specified directory path entries. AppArmor suggests
        file permission access. For more information about this, refer to
        <a class="xref" href="cha.apparmor.profiles.html#sec.apparmor.profiles.perm" title="20.7. File Permission Access Modes">Section 20.7, &#8220;File Permission Access Modes&#8221;</a>.
       </p></dd><dt><span class="term">Deny</span></dt><dd><p>
        Prevents the program from accessing the specified directory path
        entries. AppArmor then continues to the next event.
       </p></dd><dt><span class="term">New</span></dt><dd><p>
        Prompts you to enter your own rule for this event, allowing you to
        specify whatever form of regular expression you want. If the
        expression entered does not actually satisfy the event that prompted
        the question in the first place, AppArmor asks for confirmation and lets
        you reenter the expression.
       </p></dd><dt><span class="term">Glob</span></dt><dd><p>
        Select either a specific path or create a general rule using wild
        cards that matches on a broader set of paths. To select any of the
        offered paths, enter the number that is printed in front of the
        paths then decide how to proceed with the selected item.
       </p><p>
        For more information about globbing syntax, refer to
        <a class="xref" href="cha.apparmor.profiles.html#sec.apparmor.profiles.glob" title="20.6. Paths and Globbing">Section 20.6, &#8220;Paths and Globbing&#8221;</a>.
       </p></dd><dt><span class="term">Glob w/Ext</span></dt><dd><p>
        This modifies the original directory path while retaining the
        filename extension. For example,
        <code class="filename">/etc/apache2/file.ext</code> becomes
        <code class="filename">/etc/apache2/*.ext</code>, adding the wild card
        (asterisk) in place of the filename. This allows the program to
        access all files in the suggested directory that end with the
        <code class="literal">.ext</code> extension.
       </p></dd><dt><span class="term">Abort</span></dt><dd><p>
        Aborts aa-logprof, losing all rule changes entered so far and
        leaving all profiles unmodified.
       </p></dd><dt><span class="term">Finish</span></dt><dd><p>
        Closes aa-logprof, saving all rule changes entered so far and
        modifying all profiles.
       </p></dd></dl></div></div><div class="sect3" title="23.6.3.7. aa-logprof Example 2"><div class="titlepage"><div><div><h4 class="title"><a name="sec.apparmor.commandline.profiling.summary.logprof_ex2"></a>23.6.3.7. aa-logprof Example 2<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.commandline.profiling.summary.logprof_ex2">¶</a></span></h4></div></div></div><p>
     For example, when profiling vsftpd, see this question:
    </p><pre class="screen">Profile:  /usr/sbin/vsftpd
Path:     /y2k.jpg
New Mode: r

[1 - /y2k.jpg]

(A)llow / [(D)eny] / (N)ew / (G)lob / Glob w/(E)xt / Abo(r)t / (F)inish
</pre><p>
     Several items of interest appear in this question. First, note that
     vsftpd is asking for a path entry at the top of the tree, even though
     vsftpd on
     <span>openSUSE</span>
     serves FTP files from <code class="filename">/srv/ftp</code> by default. This is
     because httpd2-prefork uses chroot and, for the portion of the code
     inside the chroot jail, AppArmor sees file accesses in terms of the chroot
     environment rather than the global absolute path.
    </p><p>
     The second item of interest is that you might want to grant FTP read
     access to all JPEG files in the directory, so you could use
     <span class="guimenu">Glob w/Ext</span> and use the suggested path of
     <code class="literal">/*.jpg</code>. Doing so collapses all previous rules
     granting access to individual <code class="literal">.jpg</code> files and
     forestalls any future questions pertaining to access to
     <code class="filename">.jpg</code> files.
    </p><p>
     Finally, you might want to grant more general access to FTP files. If
     you select <span class="guimenu">Glob</span> in the last entry, aa-logprof
     replaces the suggested path of <code class="filename">/y2k.jpg</code> with
     <code class="filename">/*</code>. Alternatively, you might want to grant even
     more access to the entire directory tree, in which case you could use
     the <span class="guimenu">New</span> path option and enter
     <code class="literal">/**.jpg</code> (which would grant access to all
     <code class="literal">.jpg</code> files in the entire directory tree) or
     <code class="filename">/**</code> (which would grant access to all files in the
     directory tree).
    </p><p>
     These items deal with read accesses. Write accesses are similar, except
     that it is good policy to be more conservative in your use of regular
     expressions for write accesses. Dealing with execute accesses is more
     complex. Find an example in
     <a class="xref" href="cha.apparmor.commandline.html#ex.apparmor.commandline.profiling.summary.genprof.learn" title="Example 23.1. Learning Mode Exception: Controlling Access to Specific Resources">Example 23.1, &#8220;Learning Mode Exception: Controlling Access to Specific Resources&#8221;</a>.
    </p><p>
     In the following example, the <code class="filename">/usr/bin/mail</code> mail
     client is being profiled and aa-logprof has discovered that
     <span class="command"><strong>/usr/bin/mail</strong></span> executes
     <span class="command"><strong>/usr/bin/less</strong></span> as a helper application to
     <span class="quote">&#8220;<span class="quote">page</span>&#8221;</span> long mail messages. Consequently, it presents this
     prompt:
    </p><pre class="screen">
/usr/bin/nail -&gt; /usr/bin/less
(I)nherit / (P)rofile / (U)nconfined / (D)eny
</pre><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>
      The actual executable file for <code class="filename">/usr/bin/mail</code>
      turns out to be <code class="filename">/usr/bin/nail</code>, which is not a
      typographical error.
     </p></td></tr></table></div><p>
     The program <code class="filename">/usr/bin/less</code> appears to be a simple
     one for scrolling through text that is more than one screen long and
     that is in fact what <code class="filename">/usr/bin/mail</code> is using it
     for. However, less is actually a large and powerful program that makes
     use of many other helper applications, such as tar and rpm.
    </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>
      Run <span class="command"><strong>less</strong></span> on a tar file or an RPM file and it shows
      you the inventory of these containers.
     </p></td></tr></table></div><p>
     You do not want to run <span class="command"><strong>rpm</strong></span> automatically when
     reading mail messages (that leads directly to a Microsoft*
     Outlook&#8211;style virus attack, because rpm has the power to install
     and modify system programs), so, in this case, the best choice is to
     use <span class="guimenu">Inherit</span>. This results in the less program
     executed from this context running under the profile for
     <code class="filename">/usr/bin/mail</code>. This has two consequences:
    </p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
       You need to add all of the basic file accesses for
       <code class="filename">/usr/bin/less</code> to the profile for
       <code class="filename">/usr/bin/mail</code>.
      </p></li><li class="listitem" style="list-style-type: disc"><p>
       You can avoid adding the helper applications, such as tar and rpm, to
       the <code class="filename">/usr/bin/mail</code> profile so that when
       <code class="filename">/usr/bin/mail</code> runs
       <code class="filename">/usr/bin/less</code> in this context, the less program
       is far less dangerous than it would be without AppArmor protection.
      </p></li></ul></div><p>
     In other circumstances, you might instead want to use the
     <span class="guimenu">Profile</span> option. This has two effects on aa-logprof:
    </p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
       The rule written into the profile uses px, which forces the
       transition to the child's own profile.
      </p></li><li class="listitem" style="list-style-type: disc"><p>
       aa-logprof constructs a profile for the child and starts building it,
       in the same way that it built the parent profile, by assigning events
       for the child process to the child's profile and asking the
       aa-logprof user questions.
      </p></li></ul></div><p>
     If a confined program forks and executes another program, aa-logprof
     sees this and asks the user which execution mode should be used when
     launching the child process. The execution modes of inherit, profile,
     unconfined or an option to deny the execution are presented.
    </p><p>
     If a separate profile exists for the child process, the default
     selection is profile. If a profile does not exist, the default is
     inherit. The inherit option, or <code class="literal">ix</code>, is described in
     <a class="xref" href="cha.apparmor.profiles.html#sec.apparmor.profiles.perm" title="20.7. File Permission Access Modes">Section 20.7, &#8220;File Permission Access Modes&#8221;</a>.
    </p><p>
     The profile option indicates that the child program should run in its
     own profile. A secondary question asks whether to sanitize the
     environment that the child program inherits from the parent. If you
     choose to sanitize the environment, this places the execution modifier
     <code class="literal">Px</code> in your AppArmor profile. If you select not to
     sanitize, <code class="literal">px</code> is placed in the profile and no
     environment sanitizing occurs. The default for the execution mode is
     <code class="literal">px</code> if you select profile execution mode.
    </p><p>
     The unconfined execution mode is not recommended and should only be
     used in cases where there is no other option to generate a profile for
     a program reliably. Selecting unconfined opens a warning dialog asking
     for confirmation of the choice. If you are sure and choose
     <span class="guimenu">Yes</span>, a second dialog ask whether to sanitize the
     environment. Choosing <span class="guimenu">Yes</span> uses the execution mode
     <code class="literal">Ux</code> in your profile. Choosing <span class="guimenu">No</span>
     uses the execution mode <code class="literal">ux</code> for your profile. The
     default value selected is <code class="literal">Ux</code> for unconfined
     execution mode.
    </p><div class="important"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Important: Running Unconfined"><tr class="head"><td width="32"><img alt="[Important]" src="admon/important.png"></td><th align="left">Running Unconfined</th></tr><tr><td colspan="2" align="left" valign="top"><p>
      Choosing <code class="literal">ux</code> is very dangerous and provides no
      enforcement of policy (from a security perspective) of the resulting
      execution behavior of the child program.
     </p></td></tr></table></div></div><div class="sect3" title="23.6.3.8. aa-unconfined&#8212;Identifying Unprotected Processes"><div class="titlepage"><div><div><h4 class="title"><a name="sec.apparmor.commandline.profiling.summary.unconfined"></a>23.6.3.8. aa-unconfined&#8212;Identifying Unprotected Processes<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.commandline.profiling.summary.unconfined">¶</a></span></h4></div></div></div><p>
     The <span class="command"><strong>aa-unconfined</strong></span> command examines open network
     ports on your system, compares that to the set of profiles loaded on
     your system, and reports network services that do not have AppArmor
     profiles. It requires <code class="systemitem">root</code> privileges and that it not be confined
     by an AppArmor profile.
    </p><p>
     aa-unconfined must be run as <code class="systemitem">root</code> to retrieve the process
     executable link from the <code class="filename">/proc</code> file system. This
     program is susceptible to the following race conditions:
    </p><div class="itemizedlist"><ul class="itemizedlist" type="bullet"><li class="listitem" style="list-style-type: disc"><p>
       An unlinked executable is mishandled
      </p></li><li class="listitem" style="list-style-type: disc"><p>
       A process that dies between <span class="command"><strong>netstat(8)</strong></span> and further
       checks is mishandled
      </p></li></ul></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>
      This program lists processes using TCP and UDP only. In short, this
      program is unsuitable for forensics use and is provided only as an aid
      to profiling all network-accessible processes in the lab.
     </p></td></tr></table></div></div></div></div><div class="sect1" title="23.7. Important Filenames and Directories"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.apparmor.commandline.filenames"></a>23.7. Important Filenames and Directories<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.apparmor.commandline.filenames">¶</a></span></h2></div></div></div><p>
   The following list contains the most important files and directories used
   by the AppArmor framework. If you intend to manage and troubleshoot your
   profiles manually, make sure that you know about these files and
   directories:
  </p><div class="variablelist"><dl><dt><span class="term"><code class="filename">/sys/kernel/security/apparmor/profiles</code>
    </span></dt><dd><p>
      Virtualized file representing the currently loaded set of profiles.
     </p></dd><dt><span class="term"><code class="filename">/etc/apparmor/</code>
    </span></dt><dd><p>
      Location of AppArmor configuration files.
     </p></dd><dt><span class="term"><code class="filename">/etc/apparmor/profiles/extras/</code>
    </span></dt><dd><p>
      A local repository of profiles shipped with AppArmor, but not enabled by
      default.
     </p></dd><dt><span class="term"><code class="filename">/etc/apparmor.d/</code>
    </span></dt><dd><p>
      Location of profiles, named with the convention of replacing the
      <code class="literal">/</code> in paths with <code class="literal">.</code> (not for the
      root <code class="literal">/</code>) so profiles are easier to manage. For
      example, the profile for the program
      <code class="filename">/usr/sbin/ntpd</code> is named
      <code class="filename">usr.sbin.ntpd</code>.
     </p></dd><dt><span class="term"><code class="filename">/etc/apparmor.d/abstractions/</code>
    </span></dt><dd><p>
      Location of abstractions.
     </p></dd><dt><span class="term"><code class="filename">/etc/apparmor.d/program-chunks/</code>
    </span></dt><dd><p>
      Location of program chunks.
     </p></dd><dt><span class="term"><code class="filename">/proc/*/attr/current</code>
    </span></dt><dd><p>
      Check this file to review the confinement status of a process and the
      profile that is used to confine the process. The <span class="command"><strong>ps
      <code class="option">auxZ</code></strong></span> command retrieves this information
      automatically.
     </p></dd></dl></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"> &gt; </span><a href="book.security.html">Security Guide</a><span class="breadcrumbs-sep"> &gt; </span><a href="part.apparmor.html">Confining Privileges with Novell AppArmor</a><span class="breadcrumbs-sep"> &gt; </span><strong><a accesskey="p" title="Chapter 22. Building and Managing Profiles with YaST" href="cha.apparmor.yast.html"><span>&#9664;</span></a>  <a accesskey="n" title="Chapter 24. Profiling Your Web Applications Using ChangeHat" href="cha.apparmor.hat.html"><span>&#9654;</span></a></strong></p></div></td></tr></table></div></body></html>

ACC SHELL 2018