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

Thu Oct 1 06:47:17 UTC 2015

On 09/30/2015 10:03 PM, Barak Azulay wrote:
>
>
> Barak
>
> On Sep 30, 2015, at 10:04, Michal Skrivanek 
> <michal.skrivanek at redhat.com <mailto:michal.skrivanek at redhat.com>> wrote:
>
>>
>> On Sep 25, 2015, at 19:40 , David Mansfield <ovirt at dm.cobite.com 
>> <mailto:ovirt at dm.cobite.com>> wrote:
>>
>>> [cross-posted to devel at ovirt.org <mailto: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

>
>
>>>
>>
>>>
>>> Does the agent lock linux consoles (VC1, VC2) "sessions" (e.g. with 
>>> vlock?)
>
> AFAIU no, Vinzenz ?
No, currently we don't however I guess we should consider that in case 
of 'Lock screen'

>
>
>>>
>>> As I understand it, console access in ovirt is managed by setting a 
>>> temporary graphics password and then generating an .ini file which 
>>> is launched by remote-viewer. This password expires after a short 
>>> period of time.  So is there a mechanism where access is denied if a 
>>> user is already connected or is this allowed?
>
>
> The  mechanism is explained above , it's the ticketing system (or 
> temporary password as you referee to it above) t. The second user will 
> not get a ticket from the ovirt-engine
>
>
>>>
>>
>> connection is not allowed unless "strict user checking" disabled in UI
>> if it is disable or you use the same pwd then the previous session is 
>> terminated and replaced (unless using that hook I mentioned).
>> But we try to treat the .vv file as a one time thing, there's 
>> delete_this_file=1 which instructs virt-viewer to remove the file 
>> upon startup, so even when browser place them on a shared drive they 
>> shouldn't be there for too long
>>
>>
>> What kind of changes do you have in mind on the SPICE side?
>> It would certainly make it easier for us as currently we kind of 
>> guess when to lockï¿½we receive multiple disconnecst(per channel) and 
>> don't really know what's going onï¿½having a direct support for this 
>> inside the spice server would be better. But it needs to allow the 
>> flexibility of different actions except desktop lock (we have 
>> "nothing", "shutdown", "logoff" I think). Perhaps a way how to signal 
>> relevant information to vdsm is enough
This is why I have reported this issue: 
https://bugs.freedesktop.org/show_bug.cgi?id=91085
Having session based events would make it easier to avoid starting the 
handling on migrations, where in some conditions there's a race which 
can cause the screen lock mechanism to kick in just in the moment the 
transfer of the VM goes over to the destination hypervisor.

>>
>> Thanks,
>> michal
>>
>>>
>>> Enough questions for now, sorry for the battering.
>
> Feel free to ask ;-)
>
>>>
>>> -- 
>>> Thanks,
>>> David Mansfield
>>> Cobite, INC.
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at ovirt.org <mailto:Devel at ovirt.org>
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at ovirt.org <mailto:Devel at ovirt.org>
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>

-- 
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20151001/d7b4a2c9/attachment-0001.html>