On 09/11/2013 10:33 AM, Chen Hanxiao wrote: > >> -----Original Message----- >> From: Daniel P. Berrange [mailto:berrange@xxxxxxxxxx] >> Sent: Tuesday, September 10, 2013 6:44 PM >> To: libvir-list@xxxxxxxxxx >> Cc: Chen Hanxiao; Daniel P. Berrange >> Subject: [PATCH] Add some notes about security considerations when using > LXC >> >> From: "Daniel P. Berrange" <berrange@xxxxxxxxxx> >> >> 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@xxxxxxxxxx> >> --- >> 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><privnet/></code> flag in the >> <code><features>....</features></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. > Yes, there are two kinds of unix sockets(man 7 unix). one is abstract, this type of unix socket is net namespace aware, and upstarts use this type of unix socket to recv/send reboot message. So in this case, we should enable net namespace. the other one is pathname, this type is not net namespace aware, since it represents a file(inode), systemd uses this type of unix socket to recv/send reboot message. In this case, we should make sure the files aren't shared between host and container, for systemd, this file is /run/systemd/private. Ack for other parts of this doc. Thanks -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list