Re: [ovirt-devel] [Spice-devel] ovirt-guest-agent behavior on disconnect

On 10/01/2015 02:47 AM, Vinzenz Feenstra wrote: > On 09/30/2015 10:03 PM, Barak Azulay wrote: >> >> >> Barak >> >> On Sep 30, 2015, at 10:04, Michal Skrivanek >> <<mailto:michal.skrivanek@redhat.com>michal.skrivanek@redhat.com> >> wrote: >> >>> >>> On Sep 25, 2015, at 19:40 , David Mansfield >>> <<mailto:ovirt@dm.cobite.com>ovirt@dm.cobite.com> wrote: >>> >>>> [cross-posted to <mailto:devel@ovirt.org>devel@ovirt.org and >>>> spice-devel(a)lists.freedesktop.org >>>> <mailto:spice-devel@lists.freedesktop.org>] >>>> >>>> Hi oVirt Devs, >>>> >>>> I'm here from the spice-devel list where we were discussing some >>>> changes to the behavior of the spice guest agent reacting to a user >>>> disconnect (of the spice console). >>> >>> Hi David, >>> great, any enhancement is good! Vinzenz, please add more details to >>> my guesses below:) >>> >>>> >>>> Some information about how the ovirt-guest-agent works would be >>>> informative if you can spare a minute. >>>> >>>> The functionality being discussed is locking the user session in the >>>> VM when the user disconnects from spice (either intentionally or >>>> unintentionally). >> >> What OSs are we talking about (the behavior is significantly different >> and each pose different challenges. >> >> >>>> >>>> Also, peripherally, how does oVirt ensure secure access by >>>> authorized users of a VM and prevent "over-the-shoulder" snooping >>>> (spice graphics session stealing) or other forms of information leak >>>> from a VM shared by multiple users. >> >> We have several mechanisms to ensure that: >> 1 - ticketing system managed by the engine, so permissions are checked >> on the ovirt-engine, if a user has permissions to connect to the vm >> than the engines sends vdsm the ticket (and it sets the ticket to the >> spice server ... Through libvirt), and than the client receives this >> ticket to present to the spice server on connect (of course this >> ticket has time expiration) >> 2 - every time the client disconnects we receive an event and >> immediately send lock desktop command to the guest (through the >> ovirt-guest-agent). This is implemented both for win and Linux but for >> a Linux guest for that to work one must work on run level 5. >> 3 - anyway since this is racy , in order to avoid session theft we do >> not allow a second user to connect to a vm when the first user >> disconnected, the second user will be able to login only after the cm >> was rebooted. >> >> >> >> >>>> >>>> So here are some questions: >>>> >>>> Can a VM be "shared" by multiple users in oVirt at all? Are there >>>> known security issues that would make this a non-recommended or >>>> fundamentally un-securable setup? >>> >>> normally no, there is a semi-supported hook to allow that with VNC >>> (and even that is slightly broken IIRC at the moment), but in general >>> we do want so support that for specific usecases >> >> The question is not clear enough, >> >> In case you mean simultaneously (2 users) than the above answer is >> relevant. >> In case you mean sequential ... Than the answer is explained above , >> and yes we allow a vm to be shared among several users or groups. >> >> >>> >>>> >>>> Does the oVirt agent lock the session on disconnect? Always / >>>> unconditionally? >> >> IIRC It will always try to lock, but we can not guarantee that the >> operation actually succeeded (long story ...) >> >> >>>> If it's configurable, where does the configuration reside - in the >>>> vm guest, on the vm host (/engine) or on the client? >>> >>> it's oVirt management UI configuration, it changes the host's >>> behavior on spice disconnect per VM >>> >>>> >>>> Does the oVirt agent lock all sessions or the current active session? >>> >>> just the active AFAIK >> >> On windows its implemented only for desktop OSs (... Xp ...win7 ...) >> we lock only the interactive session, for win server this is not >> supported , in fact we do not install the SSO mechanism at all because >> it works differently for those OSs (w2k3 , 2008, 2010) >> >> On Linux it's a bit more complicated , but we find the session of the >> user we know connected to the vm ... And send the lock command. > Actually not completely correct, currently we only lock the first, we > don't try to match the user, the current assumption is that we only > allow one user per VM therefore there can't be more than one active > session. > That said, that's how it is currently implemented. Not that this is the > best way. > >> >> As explained above since there is no guarantee for that to succeed >> than we do not allow other users to connect till the cm is rebooted. >> >> >>> >>>> >>>> How does it lock the sessions? I've looked at the code and it >>>> appears '/usr/bin/loginctl lock-sessions' is being used on machines >>>> it's provided on and something more complicated on older boxes. >>>> Does the user have a way to customize this behavior? and if so, is >>>> it VM guest, VM host or client configuration? >> >> >> AFAIR this is not configurable ... But Vinzenz should be able to give >> an accurate answer > The only configuration you can do as of ovirt/RHEV 3.6 is that you are > now able to say to perform one of the following actions on console > disconnect: > - Lock the screen > - Logout the current user > - Reboot the VM > - Shutdown the VM > - Do nothing Is the console disconnect triggered by a libvirt graphics event that is monitored? Assuming so, then the "disconnect" message is sent down to the ovirt agent over a virtio channel?