Securing xvkbd-4

[mikeslr]

Yesterday Revolverve was kind enough to publish the xvkbd-4.0-x86_64.pet, http://www.murga-linux.com/puppy/viewto ... 15#1038015 echoing its creator's warning "When invoking xvkbd from display managers such as XDM, GDM, etc., always use xvkbd with -secure option or you will have serious security risk."

AFAIK, one of the main reasons for employing a virtual keyboard is to frustrate key-loggers. Obviously an application that creates a security risk would be an undesirable side effect.

I installed it into Xenialpup64 and examined the files that created. I could not find any part of its interface by which to set the secure option, but noted these two possibilities for doing so manually:

(1) add it to the Exec argument in /usr/share/applications/xvkbd.desktop, e.g. Exec=xvkbd -secure

or, (2) a hidden config file [.xvkbd] being created in /root including such entries as "#quick_modifiers 1" --without the quotes, but all beginning with the # symbol, by adding the following to the list, e.g. #secure.

But, as I wrote, those are guesses.

Either approach is easy to do. But I don't know of any way to test whether either would be effective, ignored, or interfere with the application.

Does anyone know how to test? Or any other way to implement the secure option?

Secondary question: To what extent does the warning about use with xdm, gdm, etc. apply to a 'standard' Puppy?

[OscarTalks]

I have compiled xvkbd-4.0 in Wheezy and Stretch for use in my remasters and it looks OK so far. I don't see any way of controlling the -secure option from the main window, but there is an indication if you are secure or not if you open the main menu of xvkbd from its button in the bottom left corner. If secure, some options such as "Connect to Remote Display" will be greyed out.

Going by that, I don't think editing the config file is working, either with #secure or #secure 1
I am happy to put the -secure argument in the .desktop file as I would normally start it from the JWM menu. If starting from terminal you have the choice to use the argument or not. I am not really concerned about this myself, but it is always good to be aware of the risks.

[mikeslr]

Hi OscarTalks,

Thanks for the info and especially for providing a test. Installed the pet in Xenialpup64. Merely adding -secure to the desktop's Exec line (and restarting-x) did not accomplish anything. Perhaps a reboot might, but I doubt it.
-----
Edit: Xenialpup64 uses Radky's JWMDesk Manager and associated applications. One of which is Setup>Menu Manager. After trying a wrapper as discussed below --which worked from the wrapper & by clicking the Desktop file in /usr/share/applications but not the Menu-- it occurred to me that restarting-x might not have been the correct procedure. So, with Exec=xvkbd -secure I Menu>Setup>Menu Manager and clicked OK. xvkbd now opened from the Menu with "connect to remote display" in its window greyed-out. Also, my doubt about the effect of a reboot appears to have been too pessimistic.
-----
Starting xvkbd via a terminal, code "xvkbd -secure" opened xvkdb with this change: From xvkbd's window the option to connect to a remote display WAS greyed out. Which leads me to believe that a wrapper would work with the Desktop's Exec calling the wrapper rather than directly calling the binary.

Be back in a couple of minutes.

Well, a wrapper works. But also as the Edit above indicates all that was actually necessary when using JWMDesk Manager was to 'update' the Menu after editing xvkdb.desktop's Exec argument to read Exec=xvkbd -secure.