41 Support #
This chapter outlines maintenance-related tasks. Learn how to update AppArmor® and get a list of available man pages providing basic help for using the command line tools provided by AppArmor. Use the troubleshooting section to learn about some common problems encountered with AppArmor and their solutions. Report defects or enhancement requests for AppArmor following the instructions in this chapter.
41.1 Updating AppArmor online #
Updates for AppArmor packages are provided in the same way as any other update for SUSE Linux Enterprise Server. Retrieve and apply them exactly like for any other package that ships as part of SUSE Linux Enterprise Server.
41.2 Using the man pages #
There are man pages available for your use. In a terminal, enter
man apparmor
to open the AppArmor man page. Man pages
are distributed in sections numbered 1 through 8. Each section is
specific to a category of documentation:
Section |
Category |
---|---|
1 |
User commands |
2 |
System calls |
3 |
Library functions |
4 |
Device driver information |
5 |
Configuration file formats |
6 |
Games |
7 |
High level concepts |
8 |
Administrator commands |
The section numbers are used to distinguish man pages from each other.
For example, exit(2)
describes the exit system
call, while exit(3)
describes the exit C library
function.
The AppArmor man pages are:
aa-audit(8)
aa-autodep(8)
aa-complain(8)
aa-decode(8)
aa-disable(8)
aa-easyprof(8)
aa-enforce(8)
aa-enxec(8)
aa-genprof(8)
aa-logprof(8)
aa-notify(8)
aa-status(8)
aa-unconfined(8)
aa_change_hat(8)
logprof.conf(5)
apparmor.d(5)
apparmor.vim(5)
apparmor(7)
apparmor_parser(8)
apparmor_status(8)
41.3 More information #
Find more information about the AppArmor product at:
http://wiki.apparmor.net. Find the product
documentation for AppArmor in the installed system at
/usr/share/doc/manual
.
There is a mailing list for AppArmor that users can post to or join to communicate with developers. See https://lists.ubuntu.com/mailman/listinfo/apparmor for details.
41.4 Troubleshooting #
This section lists the most common problems and error messages that may occur using AppArmor.
41.4.1 How to react to odd application behavior? #
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. 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
aa-logprof
(Section 37.7.3.9, “aa-logprof—scanning the system log”).
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 location.
41.4.2 My profiles do not seem to work anymore … #
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 which seemed to work perfectly before you updated behaving strangely, or not working.
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. Those features are:
File Locking
Network Access Control
The
SYS_PTRACE
CapabilityDirectory 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
following:
type=AVC msg=audit(1389862802.727:13939): apparmor="DENIED" \ operation="file_lock" parent=2692 profile="/usr/bin/opera" \ name="/home/tux/.qt/.qtrc.lock" pid=28730 comm="httpd2-prefork" \ requested_mask="::k" denied_mask="::k" fsuid=30 ouid=0
Update the profile using the aa-logprof
command as
outlined below.
The new network access control syntax based on the network family and
type specification, described in
Section 34.5, “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 file under
/var/log/audit/audit.log
for entries like the
following:
type=AVC msg=audit(1389864332.233:13947): apparmor="DENIED" \ operation="socket_create" family="inet" parent=29985 profile="/bin/ping" \ sock_type="raw" pid=30251 comm="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 needs to be
explicitly stated to make sure that an application has network access.
To update the profile to the new syntax, use the
aa-logprof
command as outlined below.
The current kernel requires the SYS_PTRACE
capability, if a process tries to access files in
/proc/PID/fd/*
. New
profiles need an entry for the file and the capability, where old
profiles only needed the file entry. For example:
/proc/*/fd/** rw,
in the old syntax would translate to the following rules in the new syntax:
capability SYS_PTRACE, /proc/*/fd/** rw,
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 match a file path only. This could lead to AppArmor not being able to access a crucial directory, and thus trigger misbehavior of your application and various log messages. The following examples highlight the most important changes to the path syntax.
Using the old syntax, the following rule would allow access to files and
directories in /proc/net
. It would allow directory
access only to read the entries in the directory, but not give access to
files or directories under the directory, for example
/proc/net/dir/foo
would be matched by the asterisk
(*), but as foo
is a file or directory under
dir
, it cannot be accessed.
/proc/net/* r,
To get the same behavior using the new syntax, you need two rules
instead of one. The first allows access to the file under
/proc/net
and the second allows access to
directories under /proc/net
. Directory access can
only be used for listing the contents, not actually accessing files or
directories underneath the directory.
/proc/net/* r, /proc/net/*/ r,
The following rule works similarly both under the old and the new
syntax, and allows access to both files and directories under
/proc/net
(but does not allow a directory listing
of /proc/net/
itself):
/proc/net/** r,
To distinguish file access from directory access using the above
expression in the new syntax, use the following two rules. The first one
only allows to recursively access directories under
/proc/net
while the second one explicitly allows
for recursive file access only.
/proc/net/**/ r, /proc/net/**[^/] r,
The following rule works similarly both under the old and the new syntax
and allows access to both files and directories beginning with
foo
under /proc/net
:
/proc/net/foo** r,
To distinguish file access from directory access in the new syntax and
use the **
globbing pattern, use the following two
rules. The first one would have matched both files and directories in
the old syntax, but only matches files in the new syntax because of the
missing trailing slash. The second rule matched neither file nor
directory in the old syntax, but matches directories only in the new
syntax:
/proc/net/**foo r, /proc/net/**foo/ r,
The following rules illustrate how the use of the ?
globbing pattern has changed. In the old syntax, the first rule would
have matched both files and directories (four characters, last character
could be any but a slash). In the new syntax, it matches only files
(trailing slash is missing). The second rule would match nothing in the
old profile syntax, but matches directories only in the new syntax. The
last rule matches explicitly matches a file called
bar
under /proc/net/foo?
.
Using the old syntax, this rule would have applied to both files and
directories:
/proc/net/foo? r, /proc/net/foo?/ r, /proc/net/foo?/bar r,
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:
Put the application's profile into complain mode:
>
sudo
aa-complain
/path/to/application
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.
Update the profile according to the log entries made while running the application:
>
sudo
aa-logprof
/path/to/application
Put the resulting profile back into enforce mode:
>
sudo
aa-enforce
/path/to/application
41.4.3 Resolving issues with Apache #
After installing additional Apache modules (like
apache2-mod_apparmor
) or making configuration changes
to Apache, profile Apache again to find out if additional rules need to
be added to the profile. If you do not profile Apache again, it could be
unable to start properly or be unable to serve Web pages.
41.4.4 How to exclude certain profiles from the list of profiles used? #
Run aa-disable
PROGRAMNAME
to disable the
profile for PROGRAMNAME. This command creates
a symbolic link to the profile in
/etc/apparmor.d/disable/
. To reactivate
the profile, delete the link, and run systemctl reload
apparmor
.
41.4.5 Can I manage profiles for applications not installed on my system? #
Managing profiles with AppArmor requires you to have access to the log of
the system on which the application is running. 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, journalctl | grep
-i apparmor > path_to_logfile
) to your profile build host
and run aa-logprof -f
PATH_TO_LOGFILE.
41.4.6 How to spot and fix AppArmor syntax errors #
Manually editing 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.
#
systemctl start apparmor.service
Loading AppArmor profiles AppArmor parser error in /etc/apparmor.d/usr.sbin.squid \
at line 410: syntax error, unexpected TOK_ID, expecting TOK_MODE
Profile /etc/apparmor.d/usr.sbin.squid failed to load
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 root
,
open the profile, and correct the syntax. Reload the profile set with
systemctl reload apparmor
.
vi
The editor vi
on SUSE Linux Enterprise Server supports syntax
highlighting for AppArmor profiles. Lines containing syntax errors will
be displayed with a red background.
41.5 Reporting bugs for AppArmor #
The developers of AppArmor are eager to deliver products of the highest quality. Your feedback and your bug reports help us keep the quality high. Whenever you encounter a bug in AppArmor, file a bug report against this product:
Use your Web browser to go to http://bugzilla.suse.com/ and click .
Enter the account data of your SUSE account and click
. If you do not have a SUSE account, click and provide the required data.If your problem has already been reported, check this bug report and add extra information to it, if necessary.
If your problem has not been reported yet, select
from the top navigation bar and proceed to the page.Select the product against which to file the bug. In your case, this would be your product's release. Click
.Select the product version, component (AppArmor in this case), hardware platform, and severity.
Enter a brief headline describing your problem and add a more elaborate description including log files. You may create attachments to your bug report for screenshots, log files, or test cases.
Click
after you have entered all the details to send your report to the developers.