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

Yu Xin Huo huoyuxin at linux.vnet.ibm.com
Mon May 26 07:39:19 UTC 2014


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 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
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20140526/1b6a3f29/attachment.html>


More information about the Kimchi-devel mailing list