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

[Gao feng]

On 09/11/2013 10:33 AM, Chen Hanxiao wrote:
> 
>> -----Original Message-----
>> From: Daniel P. Berrange [mailto:berrange at redhat.com]
>> Sent: Tuesday, September 10, 2013 6:44 PM
>> To: libvir-list at redhat.com
>> Cc: Chen Hanxiao; Daniel P. Berrange
>> Subject: [PATCH] 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 | 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