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

> -----Original Message----- > From: Daniel P. Berrange [mailto:berrange@redhat.com] > Sent: Tuesday, September 10, 2013 6:44 PM > To: libvir-list(a)redhat.com > Cc: Chen Hanxiao; Daniel P. Berrange > Subject: [PATCH] Add some notes about security considerations when using LXC > > From: "Daniel P. Berrange" <berrange(a)redhat.com&gt; > > 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(a)redhat.com&gt; > --- > docs/drvlxc.html.in | 93 > +++++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 93 insertions(+) > > diff --git a/docs/drvlxc.html.in b/docs/drvlxc.html.in index 1e6aa1d..dd2e93c > 100644 > --- a/docs/drvlxc.html.in > +++ b/docs/drvlxc.html.in > @@ -168,6 +168,99 @@ 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. > +</p> > + > +<p> > +It should be noted that <code>systemd</code> has a UNIX domain socket > +hich is used for communication by <code>systemctl</code>. Thus, with a > +container that shares the host's network namespace, it will be possible > +for a user in the container to invoke operations on > +<code>systemd</code> in the same way it could if outside the container. > +In particular this would allow <code>root</code> in the container to do > +anything including shutting down the host OS. If this is not desired, > +then applications should either specify the UID/GID mapping in the > +configuration to enable user namespaces, or should set the > +<code>&lt;privnet/&gt;</code> flag in the > <code>&lt;features&gt;....&lt;/features&gt;</code> element. > +</p> There might be too much spotlight on 'systemd'. Maybe users may think that this issue only came with systemd. Actually RHEL6.4GA without systemd still suffer from the reboot issue. Some apps like upstart can send reboot request to host via unix sockets.