From Fedora Project Wiki
Line 38: Line 38:
** One problem we have with the way the kernel currently labels files, is that MCS portion of the label is applied based off the process level not the level of the directory that the file was create in.  This means when a process running as unconfined_t:s0 creates a file in a directory labeled svirt_lxc_file_t:s0:c1,c2, the file will be created as svirt_lxc_file_t:s0 and the container will not be able to use the file, until the administrator changed the label.
** One problem we have with the way the kernel currently labels files, is that MCS portion of the label is applied based off the process level not the level of the directory that the file was create in.  This means when a process running as unconfined_t:s0 creates a file in a directory labeled svirt_lxc_file_t:s0:c1,c2, the file will be created as svirt_lxc_file_t:s0 and the container will not be able to use the file, until the administrator changed the label.
This feature requires that the kernel support new policy construct to allow the policy writer to specify whether the MCS Label is inherited from the parent directory MCS Labelor from the creating process MCS Label.
This feature requires that the kernel support new policy construct to allow the policy writer to specify whether the MCS Label is inherited from the parent directory MCS Labelor from the creating process MCS Label.
* libvirt  
kernel-3.3 should have this feature.
** Has to be able to launch the container with a new SELinux context for containers,
* libvirt-sandbox package introduced in Fedora 17
** potentially libvirt will have to mount a container file image with a random MCS label
** virt-sandbox-service script used for creating/starting/stopping Secure Containers
* sandboxcontainer
*** Create
** New tool needs to be created which will look at the content related to an executable, by examining the rpm database, then optionally create an image file or a directory on disk and populate the image/directory with the default content to be used for the container. It will also create the XML database used by libvirt and actually create the virtual machine definition. Finally it will create a default "init" which libvirt will execute when it starts the linux container.
**** Create an image file or a directory on disk and populate the image/directory with the default content based on the rpm data associated with the executable.
**** It will also create the virt-sandbox database used by libvirt-sandbox to create a libvirt-lxc container.
**** Create systemd unit files that will allow an admin to start and stop linux containers just like any other servers.
*** Start
**** Convert the Linux-sandbox configuration into libvirt-lxc configuration and tell libvirt to start container.
**** Container will execute dhcpd to connect the network, as well as the executable specified during creation.
**** Container will also start a shell to allow an administrator to connect to the console to debug what is going on within the container.
*** Stop
**** Stop the container, and remove it from libvirt
*** Delete
**** Delete all content related to the container
*** Connect
**** Connect to the running container administrative shell


== How To Test ==
== How To Test ==

Revision as of 16:46, 19 January 2012

Feature Name

Create a tool sandboxcontainer that will allow an administrator to easily create a LXC Container to run the an application server, with libvirt and SELinux locking it down.

Summary

This change allows an administrator to run multiple services on the same machine each service in a secure Linux Container. sandboxcontainer takes an executable and sets up all of the mountpoints and libvirt container information to run the application within the container. Then libvirt will be able to launch the container with a SELinux context that will prevent the containers process from interacting with other process on the system including other containers. This could allow an administrator to run multiple web servers simultaneously each with their own data and sharing the system data, even running as root, but prevent them from breaking the host machine or other processes on the system.

Owner

  • Email: dwalsh@redhat.com

Current status

  • Targeted release: [Fedora 17]
  • Last updated: Thu Jan 19 2012
  • Percentage of completion: 50%


Detailed Description

libvirt as of Fedora 16 has the ability to run processes within a container, the problem with this is the processes can run as root and can easily break out of the container. Also it is fairly difficult to setup one of these containers to run a particular service, for example apache.

We want to make the processes of setting up these containers easier and to use SELinux and containers together to lock down the processes running within the container, meaning you could run multiple customers on a host and prevent them from attacking each other or the host.

Benefit to Fedora

Linux Containers is a low level way of doing virtualization, and allows you to run multiple copies of the same service at the same time on a system. It has some advantages over full virtualization as it does not have to wait for an entire system to boot, it can use less memory and can use the base OS, in a read/only manner.

Scope

This change effects

  • SELinux Policy writers
    • New policy has to be written to define what a confined application container is allowed to do
  • Kernel and SELinux toolchain changes
    • One problem we have with the way the kernel currently labels files, is that MCS portion of the label is applied based off the process level not the level of the directory that the file was create in. This means when a process running as unconfined_t:s0 creates a file in a directory labeled svirt_lxc_file_t:s0:c1,c2, the file will be created as svirt_lxc_file_t:s0 and the container will not be able to use the file, until the administrator changed the label.

This feature requires that the kernel support new policy construct to allow the policy writer to specify whether the MCS Label is inherited from the parent directory MCS Labelor from the creating process MCS Label. kernel-3.3 should have this feature.

  • libvirt-sandbox package introduced in Fedora 17
    • virt-sandbox-service script used for creating/starting/stopping Secure Containers
      • Create
        • Create an image file or a directory on disk and populate the image/directory with the default content based on the rpm data associated with the executable.
        • It will also create the virt-sandbox database used by libvirt-sandbox to create a libvirt-lxc container.
        • Create systemd unit files that will allow an admin to start and stop linux containers just like any other servers.
      • Start
        • Convert the Linux-sandbox configuration into libvirt-lxc configuration and tell libvirt to start container.
        • Container will execute dhcpd to connect the network, as well as the executable specified during creation.
        • Container will also start a shell to allow an administrator to connect to the console to debug what is going on within the container.
      • Stop
        • Stop the container, and remove it from libvirt
      • Delete
        • Delete all content related to the container
      • Connect
        • Connect to the running container administrative shell

How To Test

Users should be able to easily establish containers and be able to run multiple containers simultaneously.

Documentation

Release Notes

Comments and Discussion