Contact Information

  • AUTHOR Ashok Khedkar
    Associate Technical Architect
  • PUBLISHED ON May 10, 2019

What is it AppArmor?

AppArmor (“Application Armor”) is a Linux kernel security module released under the GNU General Public License that allows the system administrator to associate a security profile with each program, which restricts the capabilities of that program. AppArmor proactively protects the operating system and applications from external or internal threats, evenzero-day attacks, by enforcing good behavior and preventing even unknown application flaws from being exploited.
AppArmor security policies completely define what system resources individual applications can access, and with what privileges. A number of default policies are included with AppArmor, and using a combination of advanced static analysis and learning-based tools, AppArmor policies for even very complex applications can be deployed successfully in a matter of hours.

  • UNIX systems normally used discretionary access control (DAC) method for restricting access before Apparmor was introduced. [DAC is with Own discretion or judgment.]
  • Apparmor is a Mandatory Access Control (or MAC) system.
  • It uses LSM (Linux Security Modules) kernel enhancements to restrict programs to certain resources.
  • AppArmor does this with profiles loaded into the kernel when the system starts.

I will elaborate in the rest of the article, a bit long, how AppArmor is configured and works!!
Apparmor profiles have two modes of execution:

  • Complaining/Learning: profile violations are permitted and logged. Useful for testing and developing new profiles. (Same as disabled but log the preventions)
  • Enforced/Confined: Enforces profile policy as well as logging the violation.On Ubuntu, Apparmor logs profile violations to /var/log/messages

In Ubuntu Apparmor is installed by default. It confines applications to profiles to determine what files and permissions that a program needs access to. Some applications will come with their own properties and more can be found in the Apparmor-profiles package.
You can install Apparmor-profiles by running sudo apt-get install Apparmor-profiles.

Purpose of design

Apparmor is designed to provide easy-to-use application security for both servers and workstations. Novell AppArmor is an access control system that lets you specify per program which files the program may read, write, and execute. Apparmor secures applications by enforcing good application behavior without relying on attack signatures, so it can prevent attacks even if they are exploiting previously unknown vulnerabilities. Apparmor can restrict the activity of even the root user. Apparmor was designed as an alternative to SELinux and is designed to be easier to use.Apparmor is configured by writing a profile for an application. Profiles are written one application at a time and typically targeted at applications which have network access. These profiles are a text files which restrict or confine an application. These restrictions are in addition to the standard Linux permissions. For example, you cannot give access to a directory or file with AppArmor if such access violates the permissions.Apparmor is a security framework that prevents applications from turning into malware/compromised application.

For example:

If I run Firefox and visit a bad site that tries to install malware that will delete my home folder, Apparmor has limits on Firefox though preventing it from doing anything I don’t want (like accessing my music, documents, etc). This way even if your application is compromised, no harm can be done.

To install the apparmor-profiles package from a terminal prompt:

yast -i –install apparmor-profiles

yast -i –update Apparmor-profiles

sudo apt-get install apparmor-profiles (Ubuntu)

From the world of DAC (Before AppArmor):

DAC attributes include:

  • User may transfer object ownership to another user(s).
  • User may determine the access type of other users.
  • After several attempts, authorization failures restrict user access.
  • Unauthorized users are blind to object characteristics, such as file size, file name and directory path.
  • Object access is determined during access control list (ACL) authorization and based on user identification and/or group membership.

DAC is easy to implement and intuitive but has certain disadvantages, including:

  • Inherent vulnerabilities (Trojan horse)
  • ACL maintenance or capability
  • Grant and revoke permissions maintenance
  • Limited negative authorization power

How to check status of Apparmor status?

Checking contents of profiles file is more reliable and uniform way (across various SUSE versions) to check Apparmor status

=> cat /sys/kernel/security/apparmor/profiles (SLES & Ubuntu)
It 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.

Note: Apparmor uses the kernel standard securityfs mechanism load and monitor profiles.

securityfs is moutned on /sys/kernel/security .
/sys/kernel/security/apparmor/profiles is a virtualized file representing the currently loaded set of profiles.
=>sudo apparmor_status (SLES & Ubuntu)
sles-11-sp3-gmc2-64:~ # apparmor_status
apparmor module is loaded.
17 profiles are loaded.
17 profiles are in enforce mode.
0 profiles are in complain mode.
4 processes have profiles defined.
4 processes are in enforce mode :
/sbin/klogd (1798)
/sbin/syslog-ng (1795)
/usr/sbin/nscd (5427)
/usr/sbin/ntpd (5361)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
sles-11-sp3-gmc2-64:~ # cat
/usr/sbin/traceroute (enforce)
/usr/sbin/ntpd (enforce)
/usr/sbin/nscd (enforce)
/usr/sbin/mdnsd (enforce)
/usr/sbin/identd (enforce)
/usr/sbin/avahi-daemon (enforce)
/usr/lib/PolicyKit/polkitd (enforce)
/usr/lib/PolicyKit/polkit-revoke-helper (enforce)
/usr/lib/PolicyKit/polkit-resolve-exe-helper (enforce)
/usr/lib/PolicyKit/polkit-read-auth-helper (enforce)
/usr/lib/PolicyKit/polkit-grant-helper-pam (enforce)
/usr/lib/PolicyKit/polkit-grant-helper (enforce)
/usr/lib/PolicyKit/polkit-explicit-grant-helper (enforce)
/sbin/syslogd (enforce)
/sbin/syslog-ng (enforce)
/sbin/klogd (enforce)
/bin/ping (enforce)

To start apparmor in enforcement mode:

aa-enforce /etc/apparmor.d (SLES)

sudo aa-enforce /path/to/bin(Ubuntu)

To start apparmor in complain mode:

aa-complain /etc/apparmor.d (SLES)

sudo aa- complain /path/to/bin (Ubuntu)

The /etc/apparmor.d directory is where the AppArmor profiles are located. It can be used to manipulate the mode of all profiles.

Enter the following to place all profiles into complain mode (Ubuntu):

sudo aa-complain /etc/apparmor.d/*

To place all profiles in enforce mode:

sudo aa-enforce /etc/apparmor.d/*

What are AppArmor Profiles?

Profiles are stored in /etc/apparmor.d/ and are named after the full path to the executable they are going to profile, replacing ‘/’ with ‘.’ For example /etc/apparmor.d/ is the profile for ping command in /bin directory.
There are two main type of rules used in profiles:

  • Path Entries determine what files an application can access.
  • Capability entries determine what privileges a process can use.

Take the profile for ping, located in etc/apparmor.d/, as an example. Profiles are comprised of 4 sections #include, capability entries(permission checking), rules, and hats.
#include <tunables/global> #include
/bin/ping flags=(complain) { # sets the mode to complain.
#include <abstractions/base>
#include <abstractions/consoles>
#include <abstractions/nameservice>
capability net_raw, # Capability entries
capability setuid, # Capability entries
network inet raw, # Network Rules
/bin/ping mixr,
/etc/modules.conf r,
#include <tunables/global> Includes the file global in the directory tunables, this allows statements
pertaining to multiple applications to be placed in a common file.
/bin/ping flags=(complain)sets the path to the profiled program and sets the mode to complain.

Capability entries:

capability net_raw allows the application access to the CAP_NET_RAW Posix.1e capability.

This is permission checking.

Capabilities statements are simply the word capability followed by the name of the POSIX.1e[POSIX (Portable Operating System Interface) family of standards on Linux . It’s a powerful file system permission model called ” POSIX Access Control Lists [ACL] on Linux”] The only capabilities a confined process may use may be enumerated; for the complete list, please
refer to capabilities(7).
Note that granting some capabilities renders Apparmor confinement for that domain advisory; while open(2), read(2), write(2), etc., will still return error when access is not granted, some capabilities allow loading kernel modules, arbitrary access to IPC, ability to bypass discretionary access controls, and other operations that are typically reserved for the root user.
The only operations that cannot be controlled in this manner are mount(2), umount(2), and loading new AppArmor policy into the kernel, which are always denied to confined processes.

Network Rules:

AppArmor supports simple coarse grained network mediation. The network rule restrict all socket(2) based operations. The mediation done is a course grained check on whether a socket of a given type and family can be created, read, or written.
There is no mediation based of port number or protocol beyond tcp, udp, and raw.AppArmor network rules are accumulated so that the granted network permissions are the union of all the listed network rule permissions.

AppArmor network rules are broad and general and become more restrictive as further information is specified.

network, #allow access to all networking network
tcp, #allow access to tcp network
inet tcp, #allow access to tcp only for inet4 addresses network
inet6 tcp, #allow access to tcp only for inet6 addresses network


/bin/ping mixr allows the application read and execute access to the file.

/etc/modules.conf r, The r gives the application read privileges for /etc/modules.conf

These are basically a set of permissions applied to files or directories. The syntax is a path followed by a

set of rules.

[path] [rules]


You may use Globing or special characters in the path.

Rules for files include


r = read

w = write

l = link

k = lock

a = append

Rules for executable (applications) include


ix = inherit = Inherit the parent’s profile.

px = requires a separate profile exists for the application, with environment scrubbing.

Px = requires a separate profile exists for the application, without environment scrubbing.

ux and Ux = Allow execution of an application unconfined, with and without environmental scrubbing. (use with

caution if at all).

m = allow executable mapping.

[“Environment scrubbing” is the removal of various “dangerous” environment variables which may be
used to affect the behavior of a binary. scrubbed environment is more secure]

Rules in detail:

l – Link mode

Allows the program to be able to create a link with this name. When a link is created, the new link MUST have a subset of permissions as the original file (with exception that the destination does not have to have link access.) If there is an ‘x’ rule on the new link, it must
match the original file exactly.

k – lock mode

Allows the program to be able lock a file with this name. This permission covers both advisory and mandatory locking.

ix – Inherit execute mode

Prevent the normal AppArmor domain transition on execve(2) when the profiled program executes the named program. Instead, the executed resource will inherit the current profile.This mode is useful when a confined program needs to call another confined program without gaining the permissions of the target’s profile, or losing the permissions of the current profile. There is no
version to scrub the environment because ‘ix’ executions don’t change privileges.
Incompatible with ‘Ux’, ‘ux’, ‘Px’, ‘px’. Implies ‘m’.

px – Discrete Profile execute mode

This mode requires that a discrete security profile is defined transition. If there is no profile defined then the access WARNING ‘px’ does not scrub the environment of variables such for a program executed and forces an AppArmor domain will be LD_PRELOAD; as a result, the calling domain may have an undue amount of influence over the callee.

Incompatible with ‘Ux’, ‘ux’, ‘Px’, ‘ix’.

Px – Discrete Profile execute mode — scrub the environment ‘Px’ allows the named program to run in ‘px’ mode, but AppArmor will invoke the Linux Kernel’s unsafe_exec routines to scrub the environment, similar to setuid programs. (See for some information on setuid/setgid environment scrubbing.)
Incompatible with ‘Ux’, ‘ux’, ‘px’, ‘ix’.

Ux – unconfined execute — scrub the environment ‘Ux’ allows the named program to run in ‘ux’ mode, but similar to setuid programs. (See for some information AppArmor will invoke the Linux Kernel’s unsafe_exec routines to scrub the environment,on setuid/setgid environment scrubbing.) WARNING ‘Ux’ should only be used in very special cases. It Use this mode only if the child absolutely must be run
Incompatible with ‘ux’, ‘px’, ‘Px’, ‘ix’.

m – Allow executable mapping

This mode allows a file to be mapped into memory using enables the designated child processes to be run without any AppArmor protection.unconfined. Use at your own risk.mmap(2)’s PROT_EXEC flag. This flag marks the pages
executable; it is used on some architectures to provide non-
executable data pages, which can complicate exploit attempts.

AppArmor uses this mode to limit which files a well-behaved program (or all programs on architectures that enforce non-
executable memory access controls) may use as libraries, to limit the effect of invalid -L flags given to ld(1) and

While an AppArmor profile is applied to an application, there are times with a sub process of the program may need access differing from the main program. In this event, the sup process may “change hats” or use an alternate sub-profile.A profile may have more than 1 sub-profile, however the sub-profiles may not have sub-sub profiles.Right now very few applications use hats and one example is Apache.
For a more detailed explanation see

man AppArmor
man AppArmor.d

NOTE: After creating/editing a profile, you need to reload the profile for changes to take effect.


# a variable definition

@{HOME} = /home/*/ /root/

# a comment about foo.

/usr/bin/foo {

/bin/mount ux,

/dev/{,u}random r,

/etc/ r,

/etc/foo.conf r,

/etc/foo/* r,

/lib/ld-*.so* rmix,

/lib/lib*.so* r,

/proc/[0-9]** r,

/usr/lib/** r,

/tmp/ wr,

/tmp/foo.* lrw,

/@{HOME}/.foo_file rw,

# a comment about foo’s subprofile, bar.

^bar {

/lib/ld-*.so* rmix,

/usr/bin/bar rmix,

/var/spool/* rwl,



How to generate profile for an application?

Commands to generate profile :
genprof | aa-genprof
Generate or update a profile. When running, you must specify a program to profile.
If the specified program is not an absolute path, genprof searches the $PATH variable. If a profile does not exist, genprof creates one using autodep.
Syntax : sudo genprof application
Example sudo genprof firefox
This generates a profile for firefox at /etc/apparmor.d/
autodep | aa-autodep
Guess basic AppArmor profile requirements. autodep creates a stub profile for the program or application examined. The resulting profile is called approximate because it does not necessarily contain all of the profile entries that the program needs to be confined properly.
complain | aa-complain
Set an AppArmor profile to complain mode from enforce mode.
syntax : complain rule
Example : sudo complain firefox
enforce | aa-enforce
Set an AppArmor profile to enforce mode from complain mode.
syntax : enforce rule
Example : sudo enforce firefox
unconfined | aa-unconfined
Output a list of processes with open tcp or udp ports that do not have AppArmor profiles loaded.
logprof | aa-logprof

Manage AppArmor profiles. logprof is an interactive tool used to review the learning or complain mode output found in the AppArmor syslog entries and to generate new entries in AppArmor profiles.
This is used to load, or more commonly reload a profile into the kernel. After modifying (editing) a
profile use:
sudo apparmor_parser -r /etc/apparmor.d/ Where “” is the profile to re-load.(e.g.
If you prefer you can restart AppArmor (same as reload)

/etc/init.d/apparmor restart
SLES- toggling the status of AppArmor using UI:
Novell AppArmor is configured to run by default on any fresh installation of openSUSE. There are two ways of toggling the status of AppArmor:
Using YaST System Services (Runlevel)- Need reboot
Disable or enable AppArmor by removing or adding its boot script to the sequence of scripts executed on
system boot. Status changes are applied at the next system boot.

  1. Start YaST.
  2. Select System+System Services (Runlevel).
  3. Select Expert Mode.
  4. Select boot.apparmor and click Set/Reset+Disable the service.
  5. Exit the YaST Runlevel tool with Finish.

AppArmor will not be initialized on the next system boot and stays inactive until you explicitly reenable it
To toggle AppArmor’s status by using AppArmor Control Panel – without reboot

  1. Start YaST.
  2. Select Novell AppArmor+AppArmor Control Panel.
  3. Select Enable AppArmor. To disable AppArmor, uncheck this option.
  4. Exit the AppArmor Control Panel with Done.

Issue description with SDCSS:

Installer was giving message to show notice below:

NOTICE: AppArmor appears to be enabled. You need to configure AppArmor

to allow the syslog daemon to write to the SCSP Agent syslog pipe.

To configure, add the entry:

‘/scspagent/IDS/system/ids_syslog.pipe wr’

to the following two AppArmor configuration files,



and run the command:

$ service boot.apparmor reload

AppArmor’s syslog-ng (/etc/apparmor.d/sbin.syslog-ng) is too restrictive in the case where syslog-ng is

configured to write to a named pipe.

Error message and Corresponding AppArmor policy:


Dec 29 12:14:12 linux-gik6 syslog-ng[1477]: Error opening file for writing;

filename=’/var/log/ids_syslog.pipe’, error=’Permission denied (13)’


#include <tunables/global>

#define this to be where syslog-ng is chrooted


/sbin/syslog-ng {

#include <abstractions/base>

#include <abstractions/consoles>

#include <abstractions/nameservice>

… Cut out for brevity…

@{CHROOT_BASE}/var/log/** w,


AppArmor policy is good-to-go for allowing syslog-ng to write to the IDS service’s named pipe

(/var/log/ids_syslog.pipe), it’s in fact too restrictive because syslog-ng opens named pipes in read+write

mode and therefore is denied access because of the above AppArmor rule.

None of this is an issue on the other AppArmor platform (Ubuntu) because the policy rules for rsyslog

and syslogd both specify read+write access permissions in the Targeted policies. This is only a problem

on SLES running syslog-ng.

Fix details:

The suppression of a warning message that would be displayed on previous builds.

Made change to the IDS collectors syslog pipe location.

Code change to CSP installer that configures sbin.syslog-ng profile.

Reconfig sbin.syslog-ng profile if needed. Legacy syslogd and rsyslog profiles do not require any

additional configuration, therefore all of the other checks and warnings for other logger daemons have

been removed.

Modify sbin.syslog-ng profile for ids_syslog.pipe r+w permissions

Old SYMCcsp was using /var/log/scsplog/ids_syslog.pipe to communicate

With system logging daemons, But new SYMCsdcss 6.0.0 MP1 uses

/var/log/ids_syslog.pipe to receive events from system logging daemon.

Sample sbin.syslog-ng

#include <tunables/global>

#define this to be where syslog-ng is chrooted


/sbin/syslog-ng {

#include <abstractions/base>

#include <abstractions/consoles>

#include <abstractions/nameservice>

#include <abstractions/mysql>

capability chown,

capability dac_override,

capability fsetid,

capability fowner,

capability sys_tty_config,

capability sys_resource,

/dev/log w,

/dev/syslog w,

/dev/tty10 rw,

/dev/xconsole rw,

/etc/syslog-ng/* r,

@{PROC}/kmsg r,

/etc/hosts.deny r,

/etc/hosts.allow r,

/sbin/syslog-ng mr,

/usr/share/syslog-ng/** r,

# chrooted applications

@{CHROOT_BASE}/var/lib/*/dev/log w,

@{CHROOT_BASE}/var/lib/syslog-ng/syslog-ng.persist* rw,

@{CHROOT_BASE}/var/log/** w,

@{CHROOT_BASE}/var/run/ krw,

@{CHROOT_BASE}/var/run/syslog-ng.ctl rw,

/var/run/syslog-ng/additional-log-sockets.conf r,

/var/log/scsplog/ids_syslog.pipe wr,

# Added by SDCSS

@{CHROOT_BASE}/var/log/ids_syslog.pipe rw,

Testing Scenario:

Scenario 1:

Upgrade from Denali MP5 to Athens MP1


a. On fresh installation of Denali MP5, user is notified that Apparmor is enabled and logs a message for ids pipe path :
‘/var/log/scsplog/ids_syslog.pipe wr’

b. On installing the agent and updating Apparmor config files, SYSLOG events are logged successfully.

c. On upgrading the agent to Athens MP1 (with above pipe entry in config file) the installer does not show message for updated ids pipe ‘/var/log/ids_syslog.pipe wr’ informing user that Apparmor is enabled.

d. Post upgrade, SYSLOG events are successfully logged with the old ids pipe Entry in Apparmor files. New entry is not added to the files.

Scenario 2:

Athens MP1 fresh install


a. Installer correctly shows a message with latest ids pipe on performing fresh installation of latest Athens MP1 agent with Apparmor enabled.

b. On updating the Apparmor config files with the ids pipe entry, SYSLOG events are successfully logged.


When ids pipe entry is added to the apparmor config files, the installer does not log a message notifying the user that Apparmor is enabled. Observed this in case of both upgrade and fresh installation.

Post Comments

Leave a Reply