AppArmor two-stage policy load is undocumented

Bug #974089 reported by Ralf Spenneberg
This bug affects 4 people
Affects Status Importance Assigned to Milestone
apparmor (Ubuntu)
Steve Beattie
Steve Beattie

Bug Description

AppArmor is loaded to late in the boot process. Manually generated profiles by security oriented admins are activated after the daemons are started. The daemons run unconfined. This is a security vulnerability because the admin apparently has no way of activating the profile.

This can be resolved for many network services using the network-interface-security upstart job.

Please update the documentation and explain this feature.

1. Admin generates profile for vsftpd
2. Admin reboots the system
3. Vsftpd is started
4. AppArmor is loaded via sys-v-support
5. Vsftpd is unconfined because AppArmor is loaded to late.

Link the vsftpd Apparmor profile to /etc/apparmor/init/network-interface-security/. These profiles are loaded before the network interfaces are activated and most network services are started:
ln -s /etc/apparmor.d/usr.sbin.vsftpd /etc/apparmor/init/network-interface-security/

This needs to be documented!

See also bug

Revision history for this message
Ralf Spenneberg (ralq) wrote :

Applies to Ubuntu 12.04 with apparmor 2.7.102-0ubuntu2

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in apparmor (Ubuntu):
status: New → Confirmed
Revision history for this message
John Johansen (jjohansen) wrote :

Currently AppArmor's profile load is not done via upstart for various reasons see for some details.

Instead if the daemon has been switched to upstart profile load can be made dependent there as is done with /etc/init/avahi-daemon.conf

Instead of forcing all profiles to be loaded early which could affect boot speed, Ubuntu has opted to provide a split profile load (which does not seem to be documented atm) that will load some profiles early and the full profile set later in the boot sequence. To force a profile to be loaded early a symlink is dropped in


as an example. As long as the profile cache is built adding all profiles should not significantly impact boot performance

Revision history for this message
Ralf Spenneberg (ralq) wrote :

Ok. I understand that. But I think this needs to be documented prominently either in the wiki or the apparmor package. Without any documentation the admin generating his own profiles does not know how to handle the situation.

Revision history for this message
John Johansen (jjohansen) wrote :

Agreed, documentation is being written. Both a patch for the apparmor (7) man page and for the wiki

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Attached is a patch to adjust the apparmor(5) man page to (finally) document this.

summary: - AppArmor is loaded far to late in the boot process to confine services
+ AppArmor two-stage policy load is undocumented
Changed in apparmor (Ubuntu):
assignee: nobody → Jamie Strandboge (jdstrand)
importance: Undecided → Medium
milestone: none → ubuntu-12.04
status: Confirmed → In Progress
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

This has been committed to ~ubuntu-core-dev/apparmor/master/

Changed in apparmor (Ubuntu Precise):
status: In Progress → Fix Committed
assignee: Jamie Strandboge (jdstrand) → Steve Beattie (sbeattie)
tags: added: rls-p-tracking
removed: security
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Opps, of course I meant apaprmor(7), not apparmor(5).

tags: added: patch
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apparmor - 2.7.102-0ubuntu3

apparmor (2.7.102-0ubuntu3) precise; urgency=low

  [ Jamie Strandboge ]
  * debian/patches/0007-ubuntu-manpage-updates.patch: update apparmor(5)
    to describe Ubuntu's two-stage policy load and how to add utilize it
    when developing policy (LP: #974089)

  [ Serge Hallyn ]
  * debian/apparmor.init: do nothing in a container. This can be
    removed once stacked profiles are supported and used by lxc.
    (LP: #978297)

  [ Steve Beattie ]
  * debian/patches/0008-apparmor-lp963756.patch: Fix permission mapping
    for change_profile onexec (LP: #963756)
  * debian/patches/0009-apparmor-lp959560-part1.patch,
    debian/patches/0010-apparmor-lp959560-part2.patch: Update the parser
    to support the 'in' keyword for value lists, and make mount
    operations aware of 'in' keyword so they can affect the flags build
    list (LP: #959560)
  * debian/patches/0011-apparmor-lp872446.patch: fix logprof missing
    exec events in complain mode (LP: #872446)
  * debian/patches/0012-apparmor-lp978584.patch: allow inet6 access in
    dovecot imap-login profile (LP: #978584)
  * debian/patches/0013-apparmor-lp800826.patch: fix libapparmor
    log parsing library from dropping apparmor network events that
    contain ip addresses or ports in them (LP: #800826)
  * debian/patches/0014-apparmor-lp979095.patch: document new mount rule
    syntax and usage in apparmor.d(5) manpage (LP: #979095)
  * debian/patches/0015-apparmor-lp963756.patch: Fix change_onexec
    for profiles without attachment specification (LP: #963756,
    LP: #978038)
  * debian/patches/0016-apparmor-lp968956.patch: Fix protocol error when
    loading policy to kernels without compat patches (LP: #968956)
  * debian/patches/0017-apparmor-lp979135.patch: Fix change_profile to
    grant access to /proc/attr api (LP: #979135)
 -- Steve Beattie <email address hidden> Thu, 12 Apr 2012 06:17:42 -0500

Changed in apparmor (Ubuntu Precise):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers