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

[Vinzenz Feenstra]

On 10/07/2015 02:52 PM, David Mansfield wrote:
>
>
> 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?
>
Yes, and yes. :-)

Sorry for being so brief, but well you got it. However, that said, we 
need to ensure that only the matching endpoint disconnect triggers the 
lock-screen mechanism, that's why I was creating the RFE/BUG on 
FDesktop.org BZ to implement some kind of session event

-- 
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com