Re: [libvirt] connect: ssh: Shall we remove the dependency of netcat ?

2015-03-31 Thread Peter Krempa
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


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] connect: ssh: Shall we remove the dependency of netcat ?

2015-03-30 Thread zhang bo
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.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list


Re: [libvirt] connect: ssh: Shall we remove the dependency of netcat ?

2015-03-27 Thread Peter Krempa
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.
  IdName   State
 
  11pxerunning
 
 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


signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] connect: ssh: Shall we remove the dependency of netcat ?

2015-03-26 Thread zhang bo
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.
 IdName   State

 11pxerunning

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?

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list