DebuggingApparmor

Differences between revisions 12 and 13
Revision 12 as of 2009-10-12 15:13:55
Size: 6421
Editor: pool-71-114-235-234
Comment: add section on tunables
Revision 13 as of 2009-10-26 14:36:54
Size: 6701
Editor: pool-71-114-235-234
Comment: add more info in 'How to file'
Deletions are marked like this. Additions are marked like this.
Line 17: Line 17:

Bugs should be filed against the package shipping the profile, not simply against the ```apparmor``` package (the exception is when the profiling bug is against an abstraction shipped by the ```apparmor``` package). Please tag apparmor profile bugs with the ```apparmor``` tag.
Line 93: Line 95:
If the log shows that the problem is not apparmor related (eg, there are no 'audit' entries in kern.log), then please reassign the bug to the package with the bug.  If the log shows that the problem is not apparmor related (eg, there are no 'audit' entries in kern.log), then please reassign the bug to the package with the bug.

Debugging Central

This page is part of the debugging series — pages with debugging details for a variety of Ubuntu packages.

Introduction

AppArmor is used by Ubuntu to protect the system from misbehaving or compromised applications. When looking at or creating bug reports, it is important to distinguish between bugs in the application and bugs in the apparmor profile for the application.

How to file

When filing a bug report regarding an apparmor profile, you need three things:

  1. The package containing the profile. Bugs should be filed against this package. Profiles are found in /etc/apparmor.d/ and you can find what package the profile belongs to with 'dpkg -S'. For example, to find out which package provides /etc/apparmor.d/usr.sbin.cupsd, use:

    $ dpkg -S /etc/apparmor.d/usr.sbin.cupsd
  2. The 'audit' entries from /var/log/kern.log, and any files in /var/log/apparmor.
  3. The steps needs to trigger the bug in the profile

Bugs should be filed against the package shipping the profile, not simply against the apparmor package (the exception is when the profiling bug is against an abstraction shipped by the apparmor package). Please tag apparmor profile bugs with the apparmor tag.

Note: please remember that it is generally not a bug in the profile if a non-default configuration is being used by the application. One example might be having mysql store its databases in /home/mysql instead of /var/lib/mysql. In these cases, the profile should just be changed by the admin.

Debugging procedure

To debug an apparmor profile, look in /var/log/kern.log for 'audit' entries. An example will look something like:

Feb  4 14:30:33 example-client kernel: [   73.459739] audit(1202153433.710:6): operation="file_mmap" request_mask="mrw::" denied_mask="m::" name="/var/lib/ldap/__db.005" pid=5375 profile="/usr/sbin/slapd" namespace="default"

The important things to look for are:

  1. 'audit(...):' -- this tells you it is an apparmor generated log entry
  2. 'profile="/usr/sbin/slapd"' -- this tells you what profile generated this message. Profiles are located in /etc/apparmor.d, and when looking for the profile, substitute '.' for the '/' from the log entry. For example, the above entry's apparmor profile is located in /etc/apparmor.d/usr.sbin.slapd

IMPORTANT: If you do not have any 'audit' entries in /var/log/kern.log at the time the application had a problem, then this is not an apparmor bug. Please see DebuggingProcedures for more information on filing a bug.

When debugging, it may also be useful to put apparmor into 'complain' mode. This will allow your application to function normally while apparmor reports accesses that are not in the profile. To enable 'complain' mode, use:

sudo aa-complain /path/to/bin

where '/path/to/bin' is the absolute path to the binary, as reported in the 'profile=...' portion of the 'audit' entry. Eg:

sudo aa-complain /usr/sbin/slapd

To re-enable enforcing mode, use 'aa-enforce' instead:

sudo aa-enforce /path/to/bin

To disable a profile:

sudo touch /etc/apparmor.d/disable/path.to.bin
sudo /etc/init.d/apparmor reload

Adjusting Tunables

AppArmor provides a mechanism for tuning your configuration without having to adjust your profiles. These tunables are stored in various files in /etc/apparmor.d/tunables. The most common tunable to adjust is /etc/apparmor.d/tunables/home. If AppArmor is denying access to files in your home directory and your home directory is not in /home, then you need to edit /etc/apparmor.d/tunables/home accordingly. For example, if your home directory is under /exports/home then change:

# @{HOMEDIRS} is a space-separated list of where user home directories
# are stored, for programs that must enumerate all home directories on a
# system. 
@{HOMEDIRS}=/home/

to be:

# @{HOMEDIRS} is a space-separated list of where user home directories
# are stored, for programs that must enumerate all home directories on a
# system. 
@{HOMEDIRS}=/home/ /exports/home/

There are other tunables available to you in /etc/apparmor.d/tunables. Most oftern, issues that are resolved by adjusted a tunable are not considered to be bugs in the profile.

Fixing profile bugs

Fixing apparmor profiles bugs is usually straightforward. Enable 'complain' mode (see above), then exercise your application. You can then either use 'aa-logprof' to walk you through the process of updating the profile, or simply edit the profile directly. Please use the 'tunables' found in /etc/apparmor.d/tunables when appropriate. Eg, rather than using a rule like:

  /home/*/ r,

use:

  @{HOME}/ r,

Once the profile is updated, reload the the profile with:

cat /etc/apparmor.d/<profile file> | sudo apparmor_parser -r
sudo /etc/init.d/apparmor reload

After the profile is working as desired, you can attach it to the bug report, stating that you have a working profile. For more on editing and creating profiles, see the community AppArmor documentation.

How to Triage

Help with triaging bugs for apparmor profiles is very welcome. To find out what exactly is the problem, we always need the 'audit' in /var/log/kern.log and if they exist, the log files in /var/log/apparmor/*. Most of the time these provide enough information to know what went wrong. If these are missing, it is recommended to ask for them with a phrase like:

Thanks for taking the time to report this bug and helping to make Ubuntu better. Could you please add '/var/log/kern.log' and the log files in '/var/log/apparmor/*' as attachments to your bug report? Thanks in advance.

If the log shows that the problem is not apparmor related (eg, there are no 'audit' entries in kern.log), then please reassign the bug to the package with the bug.

How to Forward

Forwarding of apparmor profile bugs upstream is not necessary as these profiles are Ubuntu-specific.

Known bugs

Description of known bug reports that may receive duplicates and how to recognise them. This information should be obtained by looking for bugs tagged as 'metabug'.

Open

Bug#

Description

Closed

Bug#

Description


CategoryBugSquad CategoryDebugging

DebuggingApparmor (last edited 2012-03-05 14:09:36 by jdstrand)