From 5e6a85c765c814b8eab5a01f09068ca4bb419bf3 Mon Sep 17 00:00:00 2001 From: "Daniel P. Berrange" Date: Tue, 10 Sep 2013 10:58:45 +0100 Subject: [PATCH] Add some notes about security considerations when using LXC Describe some of the issues to be aware of when configuring LXC guests with security isolation as a goal. Signed-off-by: Daniel P. Berrange --- docs/drvlxc.html.in | 103 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 103 insertions(+) diff --git a/docs/drvlxc.html.in b/docs/drvlxc.html.in index 1e6aa1d7f7..ca488f7869 100644 --- a/docs/drvlxc.html.in +++ b/docs/drvlxc.html.in @@ -168,6 +168,109 @@ Further block or character devices will be made available to containers depending on their configuration.

+

Security considerations

+ +

+The libvirt LXC driver is fairly flexible in how it can be configured, +and as such does not enforce a requirement for strict security +separation between a container and the host. This allows it to be used +in scenarios where only resource control capabilities are important, +and resource sharing is desired. Applications wishing to ensure secure +isolation between a container and the host must ensure that they are +writing a suitable configuration. +

+ +

Network isolation

+ +

+If the guest configuration does not list any network interfaces, +the network namespace will not be activated, and thus +the container will see all the host's network interfaces. This will +allow apps in the container to bind to/connect from TCP/UDP addresses +and ports from the host OS. It also allows applications to access +UNIX domain sockets associated with the host OS, which are in the +abstract namespace. If access to UNIX domains sockets in the abstract +namespace is not wanted, then applications should set the +<privnet/> flag in the +<features>....</features> element. +

+ +

Filesystem isolation

+ +

+If the guest configuration does not list any filesystems, then +the container will be set up with a root filesystem that matches +the host's root filesystem. As noted earlier, only a few locations +such as /dev, /proc and /sys +will be altered. This means that, in the absence of restrictions +from sVirt, a process running as user/group N:M inside the container +will be able to access almost exactly the same files as a process +running as user/group N:M in the host. +

+ +

+There are multiple options for restricting this. It is possible to +simply map the existing root filesystem through to the container in +read-only mode. Alternatively a completely separate root filesystem +can be configured for the guest. In both cases, further sub-mounts +can be applied to customize the content that is made visible. Note +that in the absence of sVirt controls, it is still possible for the +root user in a container to unmount any sub-mounts applied. The user +namespace feature can also be used to restrict access to files based +on the UID/GID mappings. +

+ +

+Sharing the host filesystem tree, also allows applications to access +UNIX domains sockets associated with the host OS, which are in the +filesystem namespaces. It should be noted that a number of init +systems including at least systemd and upstart +have UNIX domain socket which are used to control their operation. +Thus, if the directory/filesystem holding their UNIX domain socket is +exposed to the container, it will be possible for a user in the container +to invoke operations on the init service in the same way it could if +outside the container. This also applies to other applications in the +host which use UNIX domain sockets in the filesystem, such as DBus, +Libvirtd, and many more. If this is not desired, then applications +should either specify the UID/GID mapping in the configuration to +enable user namespaces and thus block access to the UNIX domain socket +based on permissions, or should ensure the relevant directories have +a bind mount to hide them. This is particularly important for the +/run or /var/run directories. +

+ + +

User and group isolation

+ +

+If the guest configuration does not list any ID mapping, then the +user and group IDs used inside the container will match those used +outside the container. In addition, the capabilities associated with +a process in the container will infer the same privileges they would +for a process in the host. This has obvious implications for security, +since a root user inside the container will be able to access any +file owned by root that is visible to the container, and perform more +or less any privileged kernel operation. In the absence of additional +protection from sVirt, this means that the root user inside a container +is effectively as powerful as the root user in the host. There is no +security isolation of the root user. +

+ +

+The ID mapping facility was introduced to allow for stricter control +over the privileges of users inside the container. It allows apps to +define rules such as "user ID 0 in the container maps to user ID 1000 +in the host". In addition the privileges associated with capabilities +are somewhat reduced so that they cannot be used to escape from the +container environment. A full description of user namespaces is outside +the scope of this document, however LWN has +a good write-up on the topic. +From the libvirt point of view, the key thing to remember is that defining +an ID mapping for users and groups in the container XML configuration +causes libvirt to activate the user namespace feature. +

+ +

Systemd Socket Activation Integration