[Spice-devel] [RFC PATCH] [linux-vdagent] Lock screen on disconnect

[David Mansfield]

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.