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

[David Mansfield]

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 at redhat.com>michal.skrivanek at redhat.com> wrote:
>>
>>>
>>> On Sep 25, 2015, at 19:40 , David Mansfield
>>> <<mailto:ovirt at dm.cobite.com>ovirt at dm.cobite.com> wrote:
>>>
>>>> [cross-posted to <mailto:devel at ovirt.org>devel at ovirt.org and
>>>> spice-devel at lists.freedesktop.org
>>>> <mailto:spice-devel at 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?

-- 
Thanks,
David Mansfield
Cobite, INC.