[libvirt] [PATCH v2] Add some notes about security considerations when using LXC

[Daniel P. Berrange]

On Thu, Sep 12, 2013 at 11:22:18AM +0800, Chen Hanxiao wrote:
> 
> > -----Original Message-----
> > From: Daniel P. Berrange [mailto:berrange at redhat.com]
> > Sent: Wednesday, September 11, 2013 6:57 PM
> > To: libvir-list at redhat.com
> > Cc: Gao feng; Chen Hanxiao; Daniel P. Berrange
> > Subject: [PATCH v2] Add some notes about security considerations when
> using
> > LXC
> > 
> > From: "Daniel P. Berrange" <berrange at redhat.com>
> > 
> > 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 <berrange at redhat.com>
> > ---
> >  docs/drvlxc.html.in | 103
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 103 insertions(+)
> > 
> > In v2:
> > 
> >  - Clarify UNIX domain socket issues wrt filesystem & network namespaces
> > 
> > diff --git a/docs/drvlxc.html.in b/docs/drvlxc.html.in
> > index 1e6aa1d..66d97e4 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.
> >  </p>
> > 
> > +<h2><a name="security">Security considerations</a></h2>
> > +
> > +<p>
> > +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.
> > +</p>
> > +
> > +<h3><a name="securenetworking">Network isolation</a></h3>
> > +
> > +<p>
> > +If the guest configuration does not list any network interfaces,
> > +the <code>network</code> 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
> > +<code><privnet/></code> flag in the
> > +<code><features>....</features></code> element.
> > +</p>
> > +
> 
> This section is very detailed and helpful for developers, but sys admins may
> not 
> aware of issues like reboot.
> Maybe some warnings about 'reboot issue' for sys admins are still needed.
> 
> How about keep the v1 patch's description:
> Lacking of <code>network</code> namespace would allow <code>root</code>
> in the container to do anything including shutting down the host OS.

Gao mentioned that UNIX domain sockets in the filesystem namespace
are not affected by network namespaces. Systemd uses a filesystem
based socket, so it is filesystem namespaces which are important
to restrict access to systemd & thus reboot. I already mention
this later:

> > +<p>
> > +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 <code>systemd</code> and <code>upstart</code>
> > +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 & 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
> > +<code>/run</code> or <code>/var/run</code> directories.
> > +</p>

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|