On 09/23/2015 10:56 AM, Michal Suchanek wrote:
Hello,
On Wed, Sep 23, 2015 at 10:05:40AM -0400, David Mansfield wrote:
Hi,
The attached is a very simple patch, which is working but possibly not
suitable for inclusion at this point, that locks the x11 session when the
client disconnects.
Locking is performed using "xdg-screensaver lock", which seems like an ok
implementation given that "xdg-open" is used in the file-transfer code.
I looked at the ovirt-guest-agent code and that agent also locks the session
on disconnect unless specifically disabled.
Citrix (ICAClient) sessions also automatically lock when the client
disconnects.
Other thoughts:
1) Should text consoles be considered? (me: NO)
2) Does GDM need any special exception? (me: needs to be tested)
3) Is there any point checking the exit status of the lock command? (me: NO)
4) Should the lock command be configurable? (me: grumble)
I don't think this is particularly awesome feature for protocol aimed at
virtualization (as opposed to remote connection to existing physical
desktop).
On a physical desktop locking the screen on disconnect (eg network
problem) can be useful because you do not know what people have access
to the physical desktop in some cases.
On virtual desktop security is achieved by authenticating the user on
connecting to the virtual desktop. If you want shared virtual machine
with per-user authentication you should export the individual user
desktops as opposed to the whole vitual machine.
That's not possible with spice, and we are talking about spice here.
There are a few VM's that multiple people need to use and while there's
a way (using libvirt) to prevent access while someone is connected (by
wrapping the entire spice/graphics password management in some layers)
there's no way once they disconnect to prevent subsequent connection by
a different user but only if the haven't locked their screen.
Any solution for
secure desktop sharing when you cannot tell who else is virtually
looking over your shoulder is going to be imperfect at best.
It may be imperfect but that shouldn't stop improvements from being made.
You
yourself excluded the virtual consoles - for what reason?
I simply don't know how it could be implemented. See above - perfect is
the enemy of good.
Should they
not be secured as much as graphical desktops?
Yes, but the exposure is much less. We're talking about a "don't do
that" situation - I want users to be able to use a shared VM where if
they are forced out (by losing access say) that they can be assured that
the desktop is locked and a "switch user" box is present, which is how
it works with this patch.
But I don't understand, are you now arguing that the virtual machine
SHOULD be secured or shouldn't? Can you justify why a login session
that no-one is connected to should remain unlocked?
Have you considered that
it's possible to run multiple graphical desktops on the machine?
Yes. And they should all be locked when not in use. Hence the patch.
On the other hand, if you achive running enough of the spice agent in
the user session that the user can connect only when his graphical
session is running and only to his own desktop then you have the desired
security and the locking is again non-issue because the user can only
connect to his session and when another user connects he connects to his
own session.
The graphical desktop starts after the user log's in, and that's when
the agent starts. You've got the cart before the horse here.
However, when you are there you can run the xdg-screensaver
because you are running (part of) the ageent in the user session context
(with pointers to the correct X11, dbus and whatnot sockets) and the
script then presumably knows which screensaver is to be invoked.
That's exactly what's happening. The user's portion of the agent is
running inside the X11 session where the graphical desktop is.
There are (non-spice) solutions for starting Xvfb or similar on demad
when a user tries to connect to a virtual desktop server.
Feel free to discuss those features on that list. We like using spice -
it passes USB and audio and is generally pretty cool in lots of ways.
You can probably adapt one of those if nobody has done it so far.
This will be particularly interesting for USB device connections.
5) Should the lock-on-disconnect be optional and what default value? (me:
default: lock)
It should definitely be configurable.
6) If lock-on-disconnect is optional, how to configure? (me: Because the
process we care about is running in a specific user session, configuration
may be left to the user, and so possibly ~/.spice-vdagent.conf). Note:
there are other options to spice-vdagent that I can't see how anyone would
be able to control using configuration files.
7) Windows agent feature parity?
You can possibly invoke the fast user switch feature or session lock
feature which is (unlike xdg-screensaver) designed to be reasonably
secure. If you can achieve invoking it programmatically.
Thanks, I'll look into this.
--
David Mansfield
Cobite, INC.
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel