AppArmorLibvirtProfile

Differences between revisions 1 and 2
⇤ ← Revision 1 as of 2009-06-17 12:06:34 →
Size: 67
Editor: pool-71-114-225-43
Comment:
← Revision 2 as of 2009-06-17 12:48:17 → ⇥
Size: 3301
Editor: pool-71-114-225-43
Comment: initial writeup
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:

##(see the SpecSpec for an explanation)

 * '''Launchpad Entry''': UbuntuSpec:security-karmic-missing-profiles
 * '''Created''': 2009-06-17
 * '''Contributors''': jdstrand
 * '''Packages affected''': libvirt and apparmor

== 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, [[http://fedoraproject.org/wiki/Features/SVirt_Mandatory_Access_Control|sVirt]] has been merged and contains all the necessary hooks through a
plugin architecture to confine a virtual machine, and includes a SELinux
plugin. Providing an AppArmor plugin would help increase security and contain
virtual machines in Ubuntu.

== Release Note ==

Libvirt now contains AppArmor integration. By default libvirtd will use a
non-restrictive profile and virtual machines launched by libvirt can be
confined with individual AppArmor profiles.

== 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 ==

To be determined. First pass might be to simply allow creating of profile names
(ie 'labels' in libvirt parlance) by manually modifying the XML and the libvirt
profile. Eventually having dynamic labelling where a new profile is created
for each VM when the VM is started is desirable.

== Implementation ==

 * Create an AppArmor plugin for libvirt using the security plugin framework
   provided be libvirt 0.6.1.
 * Provide an unrestricted libvirt AppArmor profile (initially)
 * Provide a restricted AppArmor abstration for guest profiles to include
 * MORE HERE

== Test/Demo Plan ==

 * libvirt tests:
  * ```virsh capabilities```
  * ```virsh dominfo <guest>```
 * guest tests:
  * add a disk in the confined directory (should be allowed)
  * add a disk outside the confined directory (should be denied)
  * add a CDROM iso (should be allowed)
  * add hardware to the guest (should be allowed)
  * modifying hardware in the guest (should be allowed)
 * 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 client^1 starts guest on remote host with AppArmor (confined)
  * confined virsh client^1 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

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 a SELinux plugin. Providing an AppArmor plugin would help increase security and contain virtual machines in Ubuntu.

Release Note

Libvirt now contains AppArmor integration. By default libvirtd will use a non-restrictive profile and virtual machines launched by libvirt can be confined with individual AppArmor profiles.

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

To be determined. First pass might be to simply allow creating of profile names (ie 'labels' in libvirt parlance) by manually modifying the XML and the libvirt profile. Eventually having dynamic labelling where a new profile is created for each VM when the VM is started is desirable.

Implementation

  • Create an AppArmor plugin for libvirt using the security plugin framework

    • provided be libvirt 0.6.1.

  • Provide an unrestricted libvirt AppArmor profile (initially)

  • Provide a restricted AppArmor abstration for guest profiles to include

  • MORE HERE

Test/Demo Plan

  • libvirt tests:

    • virsh capabilities

    • virsh dominfo <guest>

  • guest tests:
    • add a disk in the confined directory (should be allowed)
    • add a disk outside the confined directory (should be denied)
    • add a CDROM iso (should be allowed)
    • add hardware to the guest (should be allowed)
    • modifying hardware in the guest (should be allowed)
  • 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 client^1 starts guest on remote host with AppArmor (confined)

    • confined virsh client^1 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

SecurityTeam/Specifications/Karmic/AppArmorLibvirtProfile (last edited 2011-05-04 13:55:02 by pool-71-114-233-7)