Update of AppArmor disables libvirtd dynamic profiles

Bug #702774 reported by mhakali
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apparmor (Ubuntu)
Jamie Strandboge
Jamie Strandboge

Bug Description

Binary package hint: apparmor

Since a while back Ubuntu provides an excellent security model for virtualized systems. This happens via dynamic apparmor profiles protecting against manipulating other virtualized system resources but also the host system itself.

Example of how it works:

# apt-get install apparmor-profiles
# aa-enforce /etc/apparmor.d/*
<start your libvirtd and virtual machines>
# apparmor_status
apparmor module is loaded.
33 profiles are loaded.
33 profiles are in enforce mode.
4 processes have profiles defined.
4 processes are in enforce mode :
   /usr/sbin/libvirtd (1928)
   /usr/sbin/named (5018)
   libvirt-d829936f-bbff-b657-afeb-b250d8083f81 (12108)
   libvirt-ec24421d-1911-4b1b-09a8-0ece48901cb8 (20030)
# ps -ef --pid 12108
101 12108 1 1 Dec11 ? 00:41:09 /usr/bin/kvm

The dynamic libvirt-<UUID> profiles are created by libvirtd on launch. They are included by /etc/apparmor.d/usr.lib.libvirt.virt-aa-helper. When you start a virtual system new files are put under /etc/apparmor.d/libvirt. /usr/lib/libvirt/virt-aa-helper then starts (hence invoking the dynamic security profile) and then forks the KVM process.

An example of enforcement looks like:

  "/var/log/libvirt/**/test_crypto.log" w,
  "/var/lib/libvirt/**/test_crypto.monitor" rw,
  "/var/run/libvirt/**/test_crypto.pid" rwk,
  "/data/servers/test/vda.img" rw,

Very nice.

This is of course until you decide to update your system. And install a new apparmor, apparmor-profile or anything triggering "service apparmor restart" (efficiently unloading and reloading all apparmor profiles).

This efficiently makes apparmor enforce the new policies on existing running applications. Unfortunately /usr/lib/libvirt/virt-aa-helper is no longer running, and more importantly no longer with the same UUID so the KVM security profiles are no longer enforced.

For a system performing automatic security updates this is almost bound to happen.


# service apparmor restart
 * Reloading AppArmor profiles [ OK ]
# apparmor_status
apparmor module is loaded.
31 profiles are loaded.
31 profiles are in enforce mode.
2 processes have profiles defined.
2 processes are in enforce mode :
   /usr/sbin/libvirtd (1928)
   /usr/sbin/named (5018)

Security is efficiently disabled.

System information:

Distributor ID: Ubuntu
Description: Ubuntu 10.10
Release: 10.10
Codename: maverick

(Thank you launchpad/ubuntu-bugs for requiring referral headers, not saving my published information hence forcing me to rewrite the same bug report again. Frustration^2 of obscurity security. HTTPS and personal accounts should be way sufficient.)

visibility: private → public
Changed in apparmor (Ubuntu):
assignee: nobody → Jamie Strandboge (jdstrand)
milestone: none → natty-alpha-3
status: New → Triaged
Revision history for this message
mhakali (ubuntu-nexticom) wrote :

Did some additional research, and managed to re-load the existing profiles by executing:

root:/etc/apparmor.d/libvirt# for i in $(ls | grep -v "\.files" | grep libvirt-); do apparmor_parser -a $i; done

# apparmor_status
apparmor module is loaded.
40 profiles are loaded.
40 profiles are in enforce mode.

However, attempting to apply these to an existing pid (according to wiki @ https://help.ubuntu.com/community/AppArmor) gives:

root:/proc/23859/attr# cat current
root:/proc/23859/attr# echo 'setprofile libvirt-27ddd6d3-01ec-85dd-3f3b-0f58cbff18fe' > current
-bash: echo: write error: Permission denied

New machines shut down and relaunched after doing the "service apparmor restart" gets correctly confined:

# apparmor_status
3 processes have profiles defined.
3 processes are in enforce mode :
   /usr/sbin/libvirtd (1928)
   /usr/sbin/named (5018)
   libvirt-2d1c701b-d5ed-8524-4ef6-fbd12419d75e (11214)
# service apparmor restart
2 processes are in enforce mode :
   /usr/sbin/libvirtd (1928)
   /usr/sbin/named (5018)

Changed in apparmor (Ubuntu Natty):
importance: Undecided → Medium
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apparmor - 2.6.0-0ubuntu1

apparmor (2.6.0-0ubuntu1) natty; urgency=low

  [ Steve Beattie ]
  * New upstream 2.6.0 release (LP: #724193)
    - Patches taken upstream and dropped:
      + 0001-ubuntu-buildd.patch
      + 0003-add-libvirt-support-to-dnsmasq.patch
      + 0004-lp698194.patch
      + 0005-aa-disable.patch
    - debian/rules: remove library path settings for mod_apparmor and
      pam_apprmor builds; upstream handles this properly now.
    - debian/apparmor-utils.install: handle upstream SubDomain.pm =>
      AppArmor.pm renaming
  * debian/lib/apparmor/functions: handle profile names with embedded
    spaces (LP: #655523)
  * debian/rules, debian/control, debian/python-libapparmor: build
    a python-libapparmor package.

  [ Jamie Strandboge ]
  * debian/copyright: update and reformat according to DEP-5
  * debian/lib/apparmor/functions: don't unload dynamically generated libvirt
    profiles on reload, restart, and force-reload (LP: #702774)
  * debian/control: use Section: python for python-libapparmor
 -- Steve Beattie <email address hidden> Thu, 24 Feb 2011 01:41:58 -0800

Changed in apparmor (Ubuntu Natty):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers