3:03 p.m.
Barak
On Sep 30, 2015, at 10:04, Michal Skrivanek <michal.skrivanek(a)redhat.com>
wrote:
On Sep 25, 2015, at 19:40 , David Mansfield <ovirt(a)dm.cobite.com> wrote:
[cross-posted to devel(a)ovirt.org and spice-devel(a)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 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.
Feel free to ask ;-)
--
Thanks,
David Mansfield
Cobite, INC.
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
1:47 a.m.
New subject: ovirt-guest-agent behavior on disconnect
This is a multi-part message in MIME format.
--------------070705030900070107040905
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
On 09/30/2015 10:03 PM, Barak Azulay wrote:
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.
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
No, currently we don't however I guess we should consider
that in case
of 'Lock screen'
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.
--
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
--------------070705030900070107040905
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 09/30/2015 10:03 PM, Barak Azulay
wrote:<br>
</div>
<blockquote cite="mid:-3339791443746581230@unknownmsgid"
type="cite">
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
<div>
<div style="direction:rtl"><br>
</div>
<br>
Barak</div>
<div>
<div style="direction:rtl"><br>
</div>
On Sep 30, 2015, at 10:04, Michal Skrivanek <<a
moz-do-not-send="true"
href="mailto:michal.skrivanek@redhat.com"><a
class="moz-txt-link-abbreviated"
href="mailto:michal.skrivanek@redhat.com">michal.skrivanek@redhat.com</a></a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div><span></span><br>
<span>On Sep 25, 2015, at 19:40 , David Mansfield <<a
moz-do-not-send="true"
href="mailto:ovirt@dm.cobite.com"><a
class="moz-txt-link-abbreviated"
href="mailto:ovirt@dm.cobite.com">ovirt@dm.cobite.com</a></a>>
wrote:</span><br>
<span></span><br>
<blockquote type="cite"><span>[cross-posted to <a
moz-do-not-send="true"
href="mailto:devel@ovirt.org"><a
class="moz-txt-link-abbreviated"
href="mailto:devel@ovirt.org">devel@ovirt.org</a></a>
and <a moz-do-not-send="true"
href="mailto:spice-devel@lists.freedesktop.org">spice-devel@lists.freedesktop.org</a>]</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>Hi oVirt
Devs,</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>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).</span><br>
</blockquote>
<span></span><br>
<span>Hi David,</span><br>
<span>great, any enhancement is good! Vinzenz, please add more
details to my guesses below:)</span><br>
<span></span><br>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>Some information about how
the
ovirt-guest-agent works would be informative if you can
spare a minute.</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>The functionality being
discussed is locking the user session in the VM when the
user disconnects from spice (either intentionally or
unintentionally).</span><br>
</blockquote>
</div>
</blockquote>
<div style="direction:rtl"><br>
</div>
<div style="direction:ltr">What OSs are we talking about (the
behavior is significantly different and each pose different
challenges.</div>
<div style="direction:rtl"><br>
</div>
<div style="direction:rtl"><br>
</div>
<blockquote type="cite">
<div>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>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.</span><br>
</blockquote>
</div>
</blockquote>
<div><br>
</div>
<div>We have several mechanisms to ensure that:</div>
<div>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)</div>
<div>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.</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<br>
<blockquote type="cite">
<div>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>So here are some
questions:</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>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?</span><br>
</blockquote>
<span></span><br>
<span>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</span><br>
</div>
</blockquote>
<div><br>
</div>
<div>The question is not clear enough,</div>
<div><br>
</div>
<div>In case you mean simultaneously (2 users) than the above
answer is relevant.</div>
<div>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.</div>
<div><br>
</div>
<br>
<blockquote type="cite">
<div><span></span><br>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>Does the oVirt agent lock
the
session on disconnect? Always /
unconditionally?</span></blockquote>
</div>
</blockquote>
<div><br>
</div>
<div>IIRC It will always try to lock, but we can not guarantee
that the operation actually succeeded (long story ...)</div>
<div><br>
</div>
<br>
<blockquote type="cite">
<div>
<blockquote type="cite"><span> If it's configurable,
where
does the configuration reside - in the vm guest, on the vm
host (/engine) or on the client?</span><br>
</blockquote>
<span></span><br>
<span>it's oVirt management UI configuration, it changes the
host's behavior on spice disconnect per VM</span><br>
<span></span><br>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>Does the oVirt agent lock
all
sessions or the current active session?</span><br>
</blockquote>
<span></span><br>
<span>just the active AFAIK</span><br>
</div>
</blockquote>
<div><br>
</div>
<div>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)</div>
<div><br>
</div>
<div>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.</div>
</blockquote>
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.<br>
That said, that's how it is currently implemented. Not that this is
the best way.<br>
<br>
<blockquote cite="mid:-3339791443746581230@unknownmsgid"
type="cite">
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<br>
<blockquote type="cite">
<div><span></span><br>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>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?</span></blockquote>
</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>AFAIR this is not configurable ... But Vinzenz should be able
to give an accurate answer</div>
</blockquote>
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:<br>
- Lock the screen<br>
- Logout the current user<br>
- Reboot the VM<br>
- Shutdown the VM<br>
- Do nothing<br>
<br>
<blockquote cite="mid:-3339791443746581230@unknownmsgid"
type="cite">
<div><br>
</div>
<br>
<blockquote type="cite">
<div>
<blockquote type="cite"><br>
</blockquote>
<span></span><br>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>Does the agent lock linux
consoles (VC1, VC2) "sessions" (e.g. with
vlock?)</span><br>
</blockquote>
</div>
</blockquote>
<div><br>
</div>
<div>AFAIU no, Vinzenz ?</div>
</blockquote>
No, currently we don't however I guess we should consider that in
case of 'Lock screen'<br>
<br>
<blockquote cite="mid:-3339791443746581230@unknownmsgid"
type="cite">
<div><br>
</div>
<br>
<blockquote type="cite">
<div>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>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?</span></blockquote>
</div>
</blockquote>
<div><br>
</div>
<div><br>
</div>
<div>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</div>
<div><br>
</div>
<br>
<blockquote type="cite">
<div>
<blockquote type="cite"><br>
</blockquote>
<span></span><br>
<span>connection is not allowed unless "strict user checking"
disabled in UI</span><br>
<span>if it is disable or you use the same pwd then the
previous session is terminated and replaced (unless using
that hook I mentioned).</span><br>
<span>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</span><br>
<span></span><br>
<span></span><br>
<span>What kind of changes do you have in mind on the SPICE
side?</span><br>
<span>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</span><br>
</div>
</blockquote>
</blockquote>
This is why I have reported this issue:
<a class="moz-txt-link-freetext"
href="https://bugs.freedesktop.org/show_bug.cgi?id=91085">ht...
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.<br>
<br>
<blockquote cite="mid:-3339791443746581230@unknownmsgid"
type="cite">
<blockquote type="cite">
<div><span></span><br>
<span>Thanks,</span><br>
<span>michal</span><br>
<span></span><br>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>Enough questions for now,
sorry
for the battering.</span><br>
</blockquote>
</div>
</blockquote>
<div><br>
</div>
<div>Feel free to ask ;-)</div>
<br>
<blockquote type="cite">
<div>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>-- </span><br>
</blockquote>
<blockquote
type="cite"><span>Thanks,</span><br>
</blockquote>
<blockquote type="cite"><span>David
Mansfield</span><br>
</blockquote>
<blockquote type="cite"><span>Cobite,
INC.</span><br>
</blockquote>
<blockquote
type="cite"><span>_______________________________________________</span><br>
</blockquote>
<blockquote type="cite"><span>Devel mailing
list</span><br>
</blockquote>
<blockquote type="cite"><span><a
moz-do-not-send="true"
href="mailto:Devel@ovirt.org">Devel@ovirt.org</a></span><br>
</blockquote>
<blockquote type="cite"><span><a
moz-do-not-send="true"
href="http://lists.ovirt.org/mailman/listinfo/devel">http://...
</blockquote>
<span></span><br>
<span>_______________________________________________</span><br>
<span>Devel mailing list</span><br>
<span><a moz-do-not-send="true"
href="mailto:Devel@ovirt.org">Devel@ovirt.org</a></span><br>
<span><a moz-do-not-send="true"
href="http://lists.ovirt.org/mailman/listinfo/devel">http://...
<span></span><br>
<span></span><br>
</div>
</blockquote>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
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</pre>
</body>
</html>
--------------070705030900070107040905--
7:52 a.m.
New subject: [Spice-devel] ovirt-guest-agent behavior on disconnect
On 10/01/2015 02:47 AM, Vinzenz Feenstra wrote:
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.
7:55 a.m.
New subject: [Spice-devel] ovirt-guest-agent behavior on disconnect
On 10/07/2015 02:52 PM, David Mansfield wrote:
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
3476
days inactive
3483
days old
3 comments
3 participants
participants (3)
-
Barak Azulay -
David Mansfield -
Vinzenz Feenstra