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

[Hongliang Wang]

On 05/26/2014 02: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.
For this part, I'd prefer access VNC through any VNC viewer after I 
created a VM, instead of only access it through Kimchi.
>
> 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
>>
>