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

[Chen Hanxiao]

> -----Original Message-----
> From: Daniel P. Berrange [mailto:berrange at redhat.com]
> Sent: Thursday, September 12, 2013 6:46 PM
> To: Chen Hanxiao
> Cc: libvir-list at redhat.com; 'Gao feng'
> Subject: Re: [PATCH v2] Add some notes about security considerations when
> using LXC
> 
> 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:
> 

Thanks for the clarification.
But on RHEL6.4, the upstart do use an abstract socket which is net namespace
aware.
We could prevent it from affecting host OS by enable net namespace.

Maybe we could insert some description about 'upstart' into Network isolation section.

Other parts looks great.

Thanks.

> > > +<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 :|