Re: [Kimchi-devel] [PATCH 0/6] Enable Kimchi authentication in console pages

on 2014/05/04 23:14, Aline Manera wrote: > On 05/04/2014 04:21 AM, Zhou Zheng Sheng wrote: >> This is a nice idea. I tested the vnc part. A problem in previous "[v3] >> Enable encryption in vm VNC console connection" is that vnc_auto.html is >> not protected by kimchi authentication, and this patch fixes the >> problem. The reason why I did not implement authentication is that the >> port 64667 for the VNC websocket traffic itself is not protected by >> Kimchi authentication. Even with this patch series, one can just git >> clone the noVNC official git repo, then open the following link in Opera >> (or Chrome?). >> >> >> file:///home/edward/src/noVNC/vnc_auto.html?port=64667&host=X.X.X.X&path=?token=NAME_OF_THE_VM&encrypt=1 >> >> Then you get the guest VNC console without logging in to Kimchi. So this >> patch does not improve anything compared to "[v3] Enable encryption in >> vm VNC console connection", and it involves another redirection which >> makes the process a bit more complicated. > I need to disagree with you. > With this patch the noVNC is protected from Kimchi perspective > (different from the previous patch), ie, > if the user wants to get the console, he does need to get it from noVNC > source code as you described above > but it will not be possible through Kimchi. > > Even with the password parameter you mentioned below, if the user has > the full URL (including the password) > he will be able to get the console from noVNC source code without > authentication. > > To the password parameter works, we need to set a random password for > each VNC connection with expiration > time (to reset it after connection is stabilized) > > So vm_connect() create a random VNC password with expiration time for > 10s (just the enough time to open > connection to noVNC) > > That way we ensure each connection has a single valid password and if > someone gets the full URL it won't be valid > anymore. > > We need to verify how much work is needed to implement this "password > with expiration time" approach. > Any help is welcome! > Had a little chat with Aline, and we have discussed two options. (1) Poxying Websocket Request JS websocket request -> nginx -> Kimchi (CherryPy) -> websockify In this way Kimchi stays in the path so it gets the chance to auth the request before the protocol upgrade. However transparent websocket reverse proxing is just a new nginx feature, and it might not work with CherryPy. The mechanism is also too complex. (2) Permanent Password Firstly we generate a random password and set it for the VM console (Spice/VNC). When the user wants to visit the console, the user will be firstly led to vms/vm_name/console and the handler firstly puts the password in the cookie, and raise an HTTP redirection to a fake "vnc_auto.html" served by websockify (HTTPs port 64667), so the user gets the chance to accept websockify server cert. Then the JS scripts in the fake "vnc_auto.html" redirects the user to the real "vnc_auto.html" served by Kimchi. At last the JS in the real "vnc_auto.html" gets the password from the cookie, and uses the password to connect to Spice/VNC via websockify. The real "vnc_auto.html" has to be served by Kimchi so that the JS in "vnc_auto.html" can get the cookies previously set by Kimchi. We should also have a "Show Console Password" button in the front-end, so the user can get the password and the user can use other tools to connect to VNC/Spice. (3) Temporary Password for Each New Console Session It works like option 2 but the a new password is generated and set each time in the "vms/vm_name/console" handler. We can alternatively provide a POST action on "vms/vm_name/set_ticket" to enable the JS set a temporary console password. Our plan is to implement option 2 firstly, if we have time, implement option 3. For VMs created outside of Kimchi, we shall still re-use option 2 but just without a password. A problem here is how do we distinguish VM managed by Kimchi and VM managed by other tools. Shall we use the meta data feature, Shao He?

>> I think instead of protecting vnc_auto.html, which is purely static >> content and not useful to protect, we should protect the VNC payload >> with password. Kimchi should start the VM with a random VNC password, >> when the user clicks the VNC link, it should links to >> >> https://server:64667/vnc_auto.html?password=XXX&port=XXX&token=XX... >> >> Since the password is random generated, and the traffic encrypted on >> HTTPs, it's actually secure. >> >> We can also improve the security by generating a new random password >> every time the user opens a new VNC session. >> >> on 2014/05/02 08:49, Aline Manera wrote: >>> From: Aline Manera <alinefm(a)br.ibm.com&gt; >>> >>> As I commented in mailing list ([v3] Enable encryption in vm VNC console connection) >>> to enable Kimchi authentication in console pages those need to be provided by >>> Kimchi server instead of websockify web server. >>> >>> I reverted the "Enable encryption in vm VNC console connection" commit, applied >>> "[PATCH v2] Enable encryption in vm console connection" path send by Mark and >>> make the changes needed to redirect user from websockify web server to Kimchi. >>> So noVNC page continues to be rendered by Kimchi. >>> >>> With all that done, I was able to enable authentication to vnc_auto.html and >>> spice.html >>> >>> Aline Manera (5): >>> Revert "Enable encryption in vm VNC console connection" >>> Make use of the mini Web server in the websockify >>> Enable Kimchi authentication in console pages >>> backend: Redirect 401 error to default page >>> UI: Redirect user to console page after logging >>> >>> Mark Wu (1): >>> Enable encryption in vm console connection