On 5/26/2014 2:27 PM, Zhou Zheng Sheng wrote:
on 2014/05/26 13:32, Yu Xin Huo wrote:

I strongly dislike the way to change password frequently.

Password is designed for user to recognize himself for authentication.
Frequently changing password make password itself meaningless to user.

As it is VNC password, this will almost make vnc unaccessible to user.
Personally, I dislike to use browser to console the VM at all.

I suspect whether there is *a justification reasonable enough* to take
the way that "changing password".

So please exactly clarify what *threat* this "change password" strategy
is protecting against?


Some back-end background.

The problem is that noVNC and HTML5 Spice traffic is carried on
websocket outside of Kimchi server. It operates as following.

noVNC --websocket--> websockify --tcp-> VNC server of the hypervisor.

Since Kimchi is out of this route, we don't have means to authenticate
user. The user can copy the noVNC page URL to another machine without
loggin to Kimchi, and he can still access VNC.

The most practical method to prevent unauthenticated user from accessing
VNC is to set VNC password on the hypervisor side. We thought of other
means, but they either requires too much work or involves too much
transport redirection.

The current approach is that, for VM created outside of Kimchi, we don't
set password and everyone can visit it. For VM created outside of Kimchi
but with VNC password, when the user connects it from noVNC, Kimchi
reads the password and passes it to noVNC. For VM created by Kimchi, it
generates a random password.
The only security hole is that VNC password is not set when an VM is created.
A random VNC password need to be generated once a VM is created to prevent any access to a VM.

So far so good. A new problem is that currently noVNC client reads
password from URL, and we don't want the password get leaked from the
URL. We can make the password expire in short time and change it every
time we connect. The whole process is transparent to the user, the
password is generated every time, and passed to noVNC. Password
generation does not affect established VNC session, it only affects new
sessions.
Password should never be exposed as clear text(unencoded or unencripted) no matter whether it is VNC password of "kimchi created VM" or "3rd party tool created".
It is predictable that kimchi need to manage a big number of VMs created by other tool.
Again, password is privacy, it should be never be exposed.

Last time I mentioned this problem, most people thought that if the user
has noVNC for Kimchi's VM, he/she would not need other VNC client. I
think this may be true in most cases, but it surprises you when you
actually want to use TigerVNC/UltraVNC/RealVNC/Virt-Viewer.
We can not afford to such an assumption with a risk to make kimchi totally fail in marketplace.
If most users prefer to use other tool like "TigerVNC/UltraVNC/RealVNC/Virt-Viewer" and kimchi has a limitation that only noVNC in kimchi can be used.
Such a disaster consumability issue will make kimchi totally fail.

A method to mitigate the pain is that back-end only generates the
password once, and have the front-end stores the generated password in
cookie. Then we can change noVNC to read password from cookie to avoid
exposing password in URL.
The backend should generate a random VNC password once a VM is created.
We will need to add UI for kimchi user to change the default VNC password to get access to VNC.

As we use https to pass the VNC password back and forth, it is safe, no need to change the password frequently.
Password stored in cookie will not be exposed in URL, password should be removed from cookie once it is used.

For this solution, just remove "change password".

    

    

      

        
On 5/20/2014 11:27 PM, shaohef@linux.vnet.ibm.com wrote:


        

          
From: ShaoHe Feng <shaohef@linux.vnet.ibm.com>

ticket support for guest

ShaoHe Feng (4):
   update API.md
   ticket in backend: add a set ticket action for VM resource
   support ticket in UI.
   set the password for spice and VNC page.

  docs/API.md                      |  4 ++++
  src/kimchi/control/vms.py        |  1 +
  src/kimchi/model/vms.py          | 28 ++++++++++++++++++++++++++++
  ui/js/src/kimchi.api.js          | 33 ++++++++++++++++++++++++++++++++-
  ui/pages/spice.html.tmpl         |  3 ++-
  ui/pages/websockify/console.html |  5 +++++
  6 files changed, 72 insertions(+), 2 deletions(-)



        

        



_______________________________________________
Kimchi-devel mailing list
Kimchi-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel