Re: [Spice-devel] [ovirt-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
<michal.skriva...@redhat.com> wrote:



On Sep 25, 2015, at 19:40 , David Mansfield
<ov...@dm.cobite.com> wrote:


[cross-posted to de...@ovirt.org and
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 

Re: [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
<michal.skriva...@redhat.com> 
wrote:




On Sep 25, 2015, at 19:40 , David Mansfield
<ov...@dm.cobite.com> wrote:


[cross-posted to de...@ovirt.org and
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 

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

[Barak Azulay]

Barak

On Sep 30, 2015, at 10:04, Michal Skrivanek 
wrote:


On Sep 25, 2015, at 19:40 , David Mansfield  wrote:

[cross-posted to de...@ovirt.org and 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.

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





Does the agent lock linux consoles (VC1, VC2) "sessions" (e.g. with vlock?)


AFAIU no, Vinzenz ?



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 

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

[Vinzenz Feenstra]

On 09/30/2015 10:03 PM, Barak Azulay wrote:



Barak

On Sep 30, 2015, at 10:04, Michal Skrivanek 
> wrote:




On Sep 25, 2015, at 19:40 , David Mansfield > wrote:


[cross-posted to de...@ovirt.org  and 
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










Does the agent lock linux consoles (VC1, VC2) "sessions" (e.g. with 
vlock?)


AFAIU no, 

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

[Michal Skrivanek]

On Sep 25, 2015, at 19:40 , David Mansfield  wrote:

> [cross-posted to de...@ovirt.org and 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).
> 
> 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.
> 
> 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

> 
> Does the oVirt agent lock the session on disconnect? Always / 
> unconditionally? 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

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

> 
> Does the agent lock linux consoles (VC1, VC2) "sessions" (e.g. with vlock?)
> 
> 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?

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

Thanks,
michal

> 
> Enough questions for now, sorry for the battering.
> 
> -- 
> Thanks,
> David Mansfield
> Cobite, INC.
> ___
> Devel mailing list
> de...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel