AppArmorLibvirtProfile

Revision 16 as of 2009-07-07 16:30:49

Clear message

Describe SecurityTeam/Specifications/AppArmorLibvirtProfile here.

Summary

Virtual machines started by libvirt run unconfined. If there is a bug in the hypervisor, a guest could potentially attack other guests or the host. Providing an AppArmor profile would help protect against this. As of libvirt 0.6.1, sVirt has been merged and contains all the necessary hooks through a plugin architecture to confine a virtual machine, and includes an SELinux plugin. Providing an AppArmor plugin would help increase security and contain virtual machines in Ubuntu.

Release Note

Libvirt now contains AppArmor integration when using KVM or QEMU. Libvirtd can be configured to launch virtual machines that are confined by uniquely restrictive AppArmor profiles. This feature significantly improves virtualization in Ubuntu by providing user-space host protection as well as guest isolation.

Rationale

Virtual machines started by libvirt run unconfined. Since virtual machines with security bugs, misconfigured software or nefarious users could be deployed, it is imperative that the host machine is protected from attack by a malicious guest and guests be isolated from each other. Generally speaking, the hypervisor takes care of this isolation, however, bugs in the hypervisor may allow attackers to circumvent the hypervisor's protections.

AppArmor can increase security and help protect the host and isolate guests in the event of bugs in the hypervisor.

Design

When a virtual machine is started, determine if a profile is currently defined for the machine, and use it if available. If not, generate a new profile for the machine based on a template, which is by default a very restrictive profile allowing access to disk files, and anything else needed to run, such as the pid and log files.

Virtual machines should have a unique profile specific to that machine. To ensure uniqueness, the profile name will be the UUID of the virtual machine. These profiles should be configurable, either by adjusting the profile template for new machines, creating/modifying the VM profile directly or through the use of AppArmor abstractions. This will allow for administrators to fine-tune confinement for individual machines if desired.

In addition to the above, initially confine libvirtd itself with a permissive (perhaps even complain-mode only) profile. libvirtd should not be allowed to create arbitrary profiles or modify profiles directly, so as to not allow libvirtd to potentially (ie via a security bug in libvirtd itself) bootstrap out of AppArmor confinement, should it be in a restrictive enforcing profile.

Note that the upstream security plugin framework in libvirt 0.6.1 only works with qemu (and kvm), and not other technologies like Xen or OpenVZ. If and when these technologies are supported by the upstream framework, AppArmor confinement should work with them as well.

Implementation

  • Create an AppArmor plugin for libvirt using the security plugin framework provided by libvirt 0.6.1. Use aa_change_profile() from (sys/apparmor.h) in the hook for virExecWithHook(). This allows libvirtd to run in it's own profile and then change to a new profile in the kvm child after fork().

  • Provide a permissive libvirt AppArmor profile (/etc/apparmor.d/usr.sbin.libvirtd)

  • Provide a restrictive AppArmor abstraction for guest profiles to include (/etc/apparmor.d/abstractions/libvirt-qemu)

  • Provide a restrictive AppArmor template to be used when generating new profiles (/etc/apparmor.d/libvirt/TEMPLATE).

  • Write virt-aa-helper which libvirtd calls to create/update the profiles and load them. This application can create a profile based on TEMPLATE, load a profile, unload a profile and delete a profile.

  • Provide a restrictive AppArmor profile for virt-aa-helper (as part of /etc/apparmor.d/usr.sbin.libvirtd)

Blocked by

Test/Demo Plan

  • libvirt tests:

    • virsh capabilities

    • virsh dominfo <guest>

    • virsh dumpxml <guest>

    • make sure that guest is confined only if libvirtd is in complain or enforcing mode. This will require:
      1. starting libvirtd with a profile enabled (guest is confined on start)

      2. starting libvirtd with a profile enabled, then running apparmor_parser -R /etc/apparmor.d/usr.sbin.libvirtd (guest is confined on start, until restart of libvirtd)

      3. starting libvirtd without a profile enabled (guest is unconfined on start)

      4. starting libvirtd without a profile enabled, then running apparmor_parser -r /etc/apparmor.d/usr.sbin.libvirtd (guest is unconfined on start (because libvirtd needs to be restarted to be confined))

  • guest tests:
  • remote vs local tests

    • guest on local host with AppArmor (confined)

    • guest local host without AppArmor (unconfined)

    • unconfined virsh client starts guest on remote host with AppArmor (confined)

    • unconfined virsh client starts guest on remote host without AppArmor (unconfined)

    • confined virsh client1 starts guest on remote host with AppArmor (confined)

    • confined virsh client1 starts guest on remote host without AppArmor (unconfined)

[1] confined virsh client means that a local libvirtd is confined, not virsh itself

Unresolved issues

To be determined.

CategorySpec