This section lists the most common problems and error messages that may occur using Novell AppArmor.
If you notice odd application behavior or any other type of application problem, you should first check the reject messages in the log files to see if AppArmor is too closely constricting your application. To check reject messages, start+ and go to . Select and for the application audit report. You can filter dates and times to narrow down the specific periods when the unexpected application behavior occurred.
If you detect reject messages that indicate that your application or service is too closely restricted by AppArmor, update your profile to properly handle your use case of the application. Do this with the Abschnitt 3.5, „Updating Profiles from Log Entries“.in YaST, as described in
If you decide to run your application or service without AppArmor
protection, remove the application's profile from
/etc/apparmor.d or move it to another
If you have been using previous versions of AppArmor and have updated your system, but kept your old set of profiles, you might notice some applications behaving strangely or not working at all which seemed to cooperate perfectly before you updated.
This version of AppArmor introduces a set of new features to the profile syntax and the AppArmor tools that might cause trouble with older versions of the AppArmor profiles. The features concerned are:
Network Access Control
Directory Path Access
The current version of AppArmor mediates file locking and introduces a new
permission mode (
k) for this. Applications requesting
file locking permission might misbehave or fail altogether if confined by
older profiles which do not explicitly contain permissions to lock files.
If you suspect this being the case, check the log file under
/var/log/audit/audit.log for entries like the
type=APPARMOR_DENIED msg=audit(1188913493.299:9304): operation="file_lock" requested_mask="k" denied_mask="k" name="/home/tux/.qt/.qtrc.lock" pid=25736 profile="/usr/bin/opera"
Update the profile using the YaST Update Profile Wizard or the aa-logprof command as outlined below.
The new network access control syntax based on the network family and type
specification, described in Abschnitt 2.1.1, „Network Access Control“, might cause
application misbehavior or even stop applications from working. If you
notice a network-related application behaving strangely, check the log
/var/log/audit/audit.log for entries like
type=APPARMOR_DENIED msg=audit(1188894313.206:9123): operation="socket_create" family="inet" sock_type="raw" protocol=1 pid=23810 profile="/bin/ping"
This log entry means that our example application, /bin/ping in this case, failed to get AppArmor's permission to open a network connection. This permission has to be explicitly stated to make sure that an application has network access. To update the profile to the new syntax, use the YaST Update Profile Wizard or the aa-logprof command as outlined below.
With this version of AppArmor, a few changes have been made to the profile
rule syntax to better distinguish directory from file access. Therefore,
some rules matching both file and directory paths in the previous version
might now just match a file path. This could lead to AppArmor not being able
to access a crucial directory at all and thus trigger misbehavior of your
application and various log messages. For example, the following rule in
the old syntax would allow read access to both the
/proc/net directory and any
Using the new syntax, this ambiguity has been disallowed. To allow access to the directory and all its child elements (files and directories), you would have to enter:
/proc/net/* r would translate to „Allow
read access to files under
/proc/net only. Ignore
any subdirectories“ according to the new rule syntax.
To find and resolve issues related to syntax changes, take some time after the update to check the profiles you want to keep and proceed as follows for each application you kept the profile for:
Make sure that AppArmor is running and that the application's profile is loaded.
Start the YaST AppArmor Control Panel and put the application's profile into complain mode. Log entries are made for any actions violating the current profile, but the profile is not enforced and the application's behavior not restricted.
Run the application covering all the tasks you need this application to be able to perform.
Start the YaST Update Profile Wizard to update the application's profile according to the log entries generated while running the application.
Once the profile is updated, put it back into enforce mode via the YaST AppArmor Control Panel.
Using the AppArmor command line tools, you would proceed as follows:
Put the application's profile into complain mode:
Run the application.
Update the profile according to the log entries made while running the application:
Put the resulting profile back into enforce mode:
Currently, it is not possible to confine KDE applications to the same extent as any other application due to the way KDE manages its processes.
If you want to confine KDE applications, choose one of the following approaches, but note that none of them is really suited for a standard setup:
As all KDE processes are children of one parent process and AppArmor cannot distinguish an individual application's process from the rest, create one huge profile to confine the entire desktop all at once. This approach is only feasible if your setup is a very limited (kiosk-type) one. Maintaining such a profile for a standard KDE desktop including all of its applications would be close to impossible.
KDE_IS_PRELINKED=1 variables force KDE to manage its
processes in a way that AppArmor can distinguish individual applications
from each other and apply profiles to them. This approach might slow
down your desktop considerably, as it turns off a crucial optimization
for speed. Note that the above mentioned environment variables have to
be set before KDM/XDM/GDM or startx are started. One way to achieve
this would be to add them to
Apache is not starting properly or it is not serving Web pages and you
just installed a new module or made a configuration change. When you
install additional Apache modules (like
apache2-mod-apparmor) or make configuration changes to
Apache, you should profile Apache again to catch any additional rules that
need to be added to the profile.
When the reporting feature generates an HTML or CSV file that exceeds the default size, the file is not sent. Mail servers have a default, hard limit for e-mail size. This limitation can impede AppArmor's ability to send e-mails that are generated for reporting purposes. If your mail is not arriving, this could be why. Consider the mail size limits and check the archives if e-mails have not been received.
AppArmor always loads and applies all profiles that are available in its
profile directory (
/etc/apparmor.d/). If you decide
not to apply a profile to a certain application, delete the appropriate
profile or move it to another location where AppArmor would not check for
Managing profiles with AppArmor requires you to have access to a the
system's log the application is running on. So you do not need to run the
application on your profile build host as long as you have access to the
machine that runs the application. You can run the application on one
system, transfer the logs (
/var/log/audit.log or, if
audit is not installed,
/var/log/messages) to your profile build host and run
Manually editing Novell AppArmor profiles can introduce syntax errors. If you attempt to start or restart AppArmor with syntax errors in your profiles, error results are shown. This example shows the syntax of the entire parser error.
localhost:~ # rcapparmor start Loading AppArmor profiles AppArmor parser error, line 2: Found unexpected character: ’h’ Profile /etc/apparmor.d/usr.sbin.squid failed to load failed
Using the AppArmor YaST tools, a graphical error message indicates which profile contained the error and requests you to fix it.
To fix a syntax error, log in to a terminal window as
open the profile, and correct the syntax. Reload the profile set with