[Kimchi-devel] [PATCH 0/4] ticket support for guest

[Zhou Zheng Sheng]

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.

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.

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.

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.

> 
> On 5/20/2014 11:27 PM, shaohef at linux.vnet.ibm.com wrote:
>> From: ShaoHe Feng <shaohef at 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 at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
> 


-- 
Zhou Zheng Sheng / 周征晟
E-mail: zhshzhou at linux.vnet.ibm.com
Telephone: 86-10-82454397