Avoiding libki client login

[zontor]

We testing with last client release 19.08 on Windows 10, and notice some issues that can allow avoidance of libki client:
1- when logon, before libki client shows up user can click some desktop icons or so, if he opens a browser then he can alt+tab to those app on libki client (think it's normal and hard to avoid this inputs since until libki client be launched) also don't see in the install the option referred in #6 to disable input was it abandoned?
2- When client is running we notice windows key is block but its possible to press ctrl+alt+del and start task manager and then kill libkiclient or also kill and start again explorer.exe and get the normal desktop.
Think if would be possible to libki client run as a service non windows admin users wouldn't be able to kill it, also if there is someway to disallow ctrl+alt+del or not allow taks manager to be launched will minimize the issue

[kylemhall]

1. I've done some experimenting and POC work for this. The commit here has the documentation: c5a79a4

2. That is beyond the abilities of Libki. The best practice is to disable ctl+alt+del from Windows administration before installing the Libki client.

[zontor]

1. Seems not working on updated windows 10 machine, tried the flag DisableInput with capital D and lower case (seems in the code it validate lower case D) but it don't block the mouse, maybe some protection of windows don't allow tempering with input controls anymore. My test machine is slower than the ones to implement, maybe would not take too much to load.
2. I can disable task manager trough local group police (since computer is not in a domain) also affect other users including administrators, but help prevent killing the client and relauching explorer.

[kylemhall]

Try downloading the very latest version of the on_startup.exe and replacing the existing one with it. We can't be sure if the version you have currently supports that feature: https://github.com/Libki/libki-client/raw/master/deploy/windows/windows/on_startup.exe

[kd7vea]

I am noticing the same issue that it takes around 15-20 seconds to launch Libki and in that time you can easily launch a browser and bypass Libki login altogether. Is there any known fix to this issue?

As for the issue of control + Alt + Delete, you can remove Task Manager from the menu which is a partial fix. you can still right-click on the start button and have access to the task manager so remember to disable that as well in your group policy settings. I spent around 8 hours configuring the registry, and making group policy changes and in conjunction with "Reboot restore RX" this is a pretty solid system.

[jfrsw]

I think the only way to actually make sure that the user will not be able to interact with the desktop at all is to make Libki replace the user shell, then configure Libki to run explorer.exe after login. I will try that later and post the results here.

[kylemhall]

Have you made any headway @jfrsw?

[jfrsw]

I'm having some problems with the machine I'm using for testing, will have to rebuild the machine and try again.

[kd7vea]

I actually followed this post https://sourceforge.net/p/libki/mailman/message/36099713/ and used the Auto Hot Key script. I modified it slightly to fit my needs and it worked great.

[jfrsw]

I have made some tests about the shell replacement, and it seems to be working fine.

In order to try this configuration:

• Inside the registry hive of the user, go to the key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies. Inside it, look for a key named System, and create it if doesn't exist. Inside the Systemkey, create a string value named Shell and set its value to the path of the Libki Client (usually C:\Program Files (x86)\Libki\libkiclient.exe).

• Inside the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run, delete the value Libki created by the installer. This is to avoid Libki opening the login screen again once the session has been opened.

• On the Libki configuration file (usually C:\ProgramData\Libki\Libki Kiosk Management System.ini), add the following under the [node] section:
  run_on_login="C:\\Windows\\explorer.exe"

With that configuration, once the Windows user session is opened, the Libki client will be run instead of the normal desktop provided by explorer.exe, so that all the options provided by the normal desktop (icons, start menu, shortcut keys, etc) will not be available. When the Libki user logs in correctly, the Libki client will execute explorer.exe, restoring the normal desktop access.

One disadvantage I see with this approach is that some of this changes have to be applied to the registry of the Windows user that will run the Libki client, which is hard to achieve at install time (the user may not even exist yet). I will try to find a way for that change to be applied in a more general way.

[kylemhall]

That is fantastic! Thanks for sharing! In theory, the installer could ask for the username of the Windows user, or just require that for this feature to work, you need to run the installer as that user.

[loidor]

I haven't used the windows client since forever, but a quick thought (and please correct me if I'm wrong):

If the no_action setting is enabled (i.e. the win user isn't logged out), explorer.exe won't close. run_on_login will still run when the libki user logs in. This will launch explorer.exe on top of explorer.exe, meaning a Windows Explorer window will pop up, since explorer.exe as a shell is already running.

I remember working on the ahk scripts in order to get it to work, so those might need some modifications this time around too.

All in all this seems like a great way to do it!

[kylemhall]

Now that you mention it @loidor I remember running into the same issue! On the other hand, no_action was really meant for testing and development.

I take it you are running on Linux now @loidor? I'd love to know what window manager you are using and the techniques you use to stop users from bypassing the login screen! It's been too long since I had to set up the client on Linux desktops.

[loidor]

Myeah, I really never saw much use for it either in the real world but if there are options, someone is surely bound to use them...

Yes, I'm running Linux Mint with Cinnamon and have been for almost three years now. I've been thinking about making a manual entry about it, but have post-poned it for about a year now, since it's somewhat lengthy and will take time to write so anyone gets it. So yeah, this isn't to be seen as a finished product, but some day I might actually turn it into a manual entry :)

Bypass prevention:
I'm running libkiclient through startup applications without a delay, and that launches it fast enough. Then I'm running a script I call demapper with a 2 second delay, because it isn't reliable with a shorter delay. That disables Alt and Super, so it's impossible to switch workspace, launch the start menu and opening the run console.

Code for demapper:

#!/bin/bash

xmodmap -e 'keycode 133='
xmodmap -e 'keycode 64='

Other bypass preventions:

• Disable the power button
• Disabling remote media popup (Nemo->Preferences->Behaviour)
• Replace the user shell with rbash chsh -s /bin/rbash USERNAME

I haven't encountered anyone terminal-savvy enough yet, but once I do I'll look into disabling kill, killall and pkill.

Autologin, backup, restore:
I've disabled the screensaver, since I don't want the client to become locked, and have an autologin set in /etc/lightdm/lightdm.conf.

Together with this, I've got a backup/restore solution where backup copies /home/USERNAME to /opt/USERNAME. restore deletes /home/USERNAME and replaces it with /opt/USERNAME. Only root can run backup when needed (after changes), and restore is run on every logout through lightdm.conf.

backup code:

#!/bin/bash

if [[ $EUID -ne 0 ]]; then
   echo "This script must be run as root" 
   exit 1
fi

rm -rf /opt/public
cp -a /home/public /opt/public
echo "Backup klar."

restore code:

#!/bin/bash

rsync -qrpog --delete --exclude '.X*' /opt/public /home/
echo "" > /home/public/.local/share/recently-used.xbel
rm /var/spool/cups/*

My lightdm.conf:

[Seat:*]
autologin-guest=false
autologin-user=public
autologin-user-timeout=5

session-cleanup-script=/usr/local/bin/restore

Other things:

• I install Google Chrome since pretty much everyone is familiar with it regardless of what system they're used to running. The keychain password is set to blank/unencrypted.
• I change LibreOffice Writer to save to docx as default.
• I add shortcuts to Chrome and Writer to the desktop.
• I remove terminal from the quick launch toolbar since most users don't know what it is.
• I remove logout and shutdown options from the start menu. (This is a PITA to do by hand, but here it goes:

In /usr/share/cinnamon/applets/menu@cinnamon.org/applet.js, find the line //Lock screen. Start a multiline comment there with /* and go to the line //Shutdown button. Somewhat close to that one, 15 lines or so, there should be a line saying this.systemButtonsBox.add(button.aactor, { y_align: St.Align.END, y_fill: false });. End your multiline comment after this line with */.

• Finally, I set my preferred volume and remove the volume icon from the toolbar. All our clients have headphones, and they can leak quite a lot if the volume is high enough.

Then there are some things specific for us, setting homepage, printer setup and things like that.

I've scripted all of this though, so the install isn't all that hard though.

[jfrsw]

That is fantastic! Thanks for sharing! In theory, the installer could ask for the username of the Windows user, or just require that for this feature to work, you need to run the installer as that user.

I'm glad you find it interesting, @kylemhall. There might be another way to handle this setting: if you set the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon Shell value to the path of the Libki Client (instead of the registry belonging to one particular user), Libki will become the default shell for all users. The client could then decide, based on the values of the onlyRunFor/onlyStopFor config setting, if it should run the client code or the default operating system shell (that could be specified with another setting like runForOtherUsers or something similar). I might try that on a feature branch and make a PR to test it.

[jfrsw]

I haven't used the windows client since forever, but a quick thought (and please correct me if I'm wrong):

If the no_action setting is enabled (i.e. the win user isn't logged out), explorer.exe won't close. run_on_login will still run when the libki user logs in. This will launch explorer.exe on top of explorer.exe, meaning a Windows Explorer window will pop up, since explorer.exe as a shell is already running.

I remember working on the ahk scripts in order to get it to work, so those might need some modifications this time around too.

All in all this seems like a great way to do it!

Thanks, @loidor! You're right, I was already facing the same problem in my tests. To deal with this, a new setting (run_on_logout maybe?) could be added to run something when the session ends, and use that to kill explorer.exe then. This way, even if no_action is configured, the next user would not find an open desktop from an already running explorer process. As in my previous comment, I might try to implement that to see how it works.