[libvirt] connect: ssh: Shall we remove the dependency of netcat ?
1 When we connect libvirt with URI "qemu+ssh", it uses 'nc' command to connect to libvirt-sock. # virsh -c qemu+ssh://root@9.61.1.74/system list Password: //ask users to input passwords here. Id Name State ---------------------------------------------------- 11 pxe running It in fact uses 'ssh' and 'nc' commands to connect to remote libvirt-sock, such as: ssh -l root 9.61.1.74 sh -c ''nc' -U /var/run/libvirt/libvirt-sock' The code path is : virConnectOpen->doRemoteOpen->virNetClientNewSSH->virNetSocketNewConnectSSH 2 However, netcat(nc) is considered as an insecure tool, because it's too powerful in controlling the network. It's abandoned by some organizations. 3 So, is there any good substitution for netcat to realize qemu+ssh?
On Fri, Mar 27, 2015 at 10:54:26 +0800, zhang bo wrote:
1 When we connect libvirt with URI "qemu+ssh", it uses 'nc' command to connect to libvirt-sock.
# virsh -c qemu+ssh://root@9.61.1.74/system list Password: //ask users to input passwords here. Id Name State ---------------------------------------------------- 11 pxe running
It in fact uses 'ssh' and 'nc' commands to connect to remote libvirt-sock, such as: ssh -l root 9.61.1.74 sh -c ''nc' -U /var/run/libvirt/libvirt-sock'
Yep.
The code path is : virConnectOpen->doRemoteOpen->virNetClientNewSSH->virNetSocketNewConnectSSH
2 However, netcat(nc) is considered as an insecure tool, because it's too powerful in controlling the network. It's abandoned by some organizations.
Too powerful? That is a ridiculous statement that probably originates from some kind of misunderstanding when creating a security policy or stuff like that. If a policy bans nc as "powerful" then it's missing on a lot of other options how to create listening or outgoing connections on arbitrary sockets. The only insecure part is that it does not use encryption, but that's a widely known fact about nc.
3 So, is there any good substitution for netcat to realize qemu+ssh?
Currently libvirt doesn't allow this, but I'm planning for a long time to introduce a standalone libvirt client binary (or perhaps add this as a mode to virsh) to replace the use of NC but that's due to other reasons: 1) nc doesn't know where session mode sockets are placed This is due to the fact that it depends on how libvirt is compiled. Currently the client side has to provide the path that is used at the remote side and those may not correspond. 2) errors reported when using the ssh connection transport are not helpful: NC is inherently bad at reporting what happened with the unix socket on the remote side. 3) getting rid of nc as a dependency This won't happen though ... old libvirt clients would not be able to connect to newer servers. In other words. I don't think libvirt will ever get rid of using nc but we can make stuff better by adding the internal remote client. Peter
On 2015/3/28 0:25, Peter Krempa wrote:
On Fri, Mar 27, 2015 at 10:54:26 +0800, zhang bo wrote:
Too powerful? That is a ridiculous statement that probably originates from some kind of misunderstanding when creating a security policy or stuff like that. If a policy bans nc as "powerful" then it's missing on a lot of other options how to create listening or outgoing connections on arbitrary sockets. The only insecure part is that it does not use encryption, but that's a widely known fact about nc.
Sorry for replying so late:) I tried to confirm the security fact the other days, unfortunately no clear answer gotten. What I meant was that the *network monitoring tools*, such as 'nc' and 'tcpdump', they are considered as dangerous for network security. They are prohibited in our company and some other organizations. I'm not quite sure whether the result that they're prohibited are directly related to their capability of monitoring network. But they actually got prohibited anyway.
3 So, is there any good substitution for netcat to realize qemu+ssh?
Currently libvirt doesn't allow this, but I'm planning for a long time to introduce a standalone libvirt client binary (or perhaps add this as a mode to virsh) to replace the use of NC but that's due to other reasons:
1) nc doesn't know where session mode sockets are placed
This is due to the fact that it depends on how libvirt is compiled. Currently the client side has to provide the path that is used at the remote side and those may not correspond.
2) errors reported when using the ssh connection transport are not helpful:
NC is inherently bad at reporting what happened with the unix socket on the remote side.
3) getting rid of nc as a dependency
This won't happen though ... old libvirt clients would not be able to connect to newer servers.
In other words. I don't think libvirt will ever get rid of using nc but we can make stuff better by adding the internal remote client.
Peter
Thank you for the detailed reply, glad to hear that it's on schedule to be replaced someday.
On Tue, Mar 31, 2015 at 09:02:23 +0800, zhang bo wrote:
On 2015/3/28 0:25, Peter Krempa wrote:
On Fri, Mar 27, 2015 at 10:54:26 +0800, zhang bo wrote:
Too powerful? That is a ridiculous statement that probably originates from some kind of misunderstanding when creating a security policy or stuff like that. If a policy bans nc as "powerful" then it's missing on a lot of other options how to create listening or outgoing connections on arbitrary sockets. The only insecure part is that it does not use encryption, but that's a widely known fact about nc.
Sorry for replying so late:) I tried to confirm the security fact the other days, unfortunately no clear answer gotten. What I meant was that the *network monitoring tools*, such as 'nc' and 'tcpdump', they are considered as dangerous for network security. They are prohibited in our company and some other organizations. I'm not quite sure whether the result that they're prohibited are directly related to their capability of monitoring network. But they actually got prohibited anyway.
That sounds like a security-by-obscurity policy. I don't think that banning such tools might have any benefit for security. Anyways I'm planing on adding the native client. In such case, companies having such ridiculous security rules may opt to uninstall netcat and rely solely on libvirt's internal client (once it's implemented). Such policy will then basically mandate a minimal version of libvirt that will support the new client as older clients will still want to use NC. Peter
participants (2)
-
Peter Krempa -
zhang bo