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.

[jfrsw]

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 :)

Nice setup, @loidor! It reminds me of the days when I could use Linux on our library's public computers... Back then, I was using an Ubuntu derivative and Gnome's lockdown settings to configure user restrictions, but that solution was never as complete as the one you have!
Last time I checked, Cinnamon did not support any lockdown options, which is a shame as it would probably be my environment of choice if I had to setup Linux computers for public use again...

[loidor]

@jfrsw A run_on_logout setting would take care of that indeed.

No, Cinnamon doesn't have any lockdown options, but it's a great DE for people used to win and mac. I'm still finding things every now and then that can be used to bypass it - or rather, I have a 10 year old kid that tries to break the system for fun every now and then and then tells me what's wrong with it. Would hire him this instant if I could.

[kylecop]

In case you haven't considered it yet, but I'm sure you already know about it.

You can use a keyboard hook, and a flag that enable and disables the function of the tab button, or any other button that you choose.
https://causeyourestuck.io/2016/04/20/keyboard-hook-win32api-2/

[kylemhall]

@jfrsw Have you tried your Winlogon idea yet? That sounds like an ideal solution!

[kylecop]

I was able to fork your repository and to get It to work. But the code was not pretty.

…

On Jan 29, 2020, at 10:13 AM, Kyle M Hall ***@***.***> wrote:  @jfrsw Have you tried your Winlogon idea yet? That sounds like an ideal solution! — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[kylemhall]

I was able to fork your repository and to get It to work. But the code was not pretty.
…
On Jan 29, 2020, at 10:13 AM, Kyle M Hall @.***> wrote:  @jfrsw Have you tried your Winlogon idea yet? That sounds like an ideal solution! — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

Can you link to the fork? I'd love to take a look!

[kylecop]

https://github.com/kylecop/libki-client

…

On Jan 29, 2020, at 11:17 AM, Kyle M Hall ***@***.***> wrote:  I was able to fork your repository and to get It to work. But the code was not pretty. … On Jan 29, 2020, at 10:13 AM, Kyle M Hall @.***> wrote:  @jfrsw Have you tried your Winlogon idea yet? That sounds like an ideal solution! — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Can you link to the fork? I'd love to take a look! — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[kylecop]

I'm sorry I didn't see you tagged @jfrsw

[jfrsw]

@kylemhall I haven't made any further progress since my first try, hope I can get a bit more of time to try out the idea of Libki deciding if it should run itself or the operating system default shell on startup based on onlyRunFor/onlyStopFor config settings.

[jfrsw]

I think I could implement the user shell replacement by adding a new option (start_user_shell) that would store the default user shell for all users of the system. Then, depending on the values of onlyRunFor and onlyStopFor:

• If onlyRunFor is set and the current user does not match, or onlyStopFor is set and it matches the username, then the Libki client will run the command specified on start_user_shell before exiting;

• If onlyRunFor is set and the current user matches, or onlyStopFor is set and it does not match the username, then the Libki client will show the login screen, and only after a successful login it will run the command specified on start_user_shell.

A similar option (stop_user_shell) could be added for the Libki client to run when the client session finishes.

This way, Libki could act as a system-wide shell replacement, and an option could be added to the installer for activating this behaviour during the initial setup.

[kylemhall]

@jfrsw I'm trying your shell replacement feature and it works great except explorer launches just a file explorer. I get no desktop or taskbar! What I've discovered is that in Windows 7 at least, if the Shell in the registry is not set to explorer.exe, it only opens a file manager window. If it is set to explorer.exe, it launches the desktop and taskbar as well.

I'm guessing you are not having this issue. What version of Windows have you tested on? I'm guessing I should upgrade to Windows 10 now that Windows 7 is out of support!

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 `System`key, 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.

[jfrsw]

@kylemhall I'm testing on Windows 10, and it doesn't seem to need the Shell key set to explorer.exe in order to launch the full desktop, that's why I was not experiencing the issue. Although Windows 7 is out of support, it's likely to be around for some time, so it would be nice to have some kind of workaround for the feature to work on Windows 7. I will set up a test installation and see if I can fix that somehow.

[kylemhall]

@kylemhall I'm testing on Windows 10, and it doesn't seem to need the Shell key set to explorer.exe in order to launch the full desktop, that's why I was not experiencing the issue. Although Windows 7 is out of support, it's likely to be around for some time, so it would be nice to have some kind of workaround for the feature to work on Windows 7. I will set up a test installation and see if I can fix that somehow.

Thanks @jfrsw !
What I tried to do was to edit the registry. Basically, on Libki logout set the shell to libkiclient.exe, and on startup ( when the Libki login page displays ) set the shell back to explorer.exe. In theory that should work, but only Administrator accounts can edit that registry key. I then made all kinds of attempts to allow libkiclient.exe or the AHK scripts to run as administrator without triggering UAC, but none of them worked. When I set libkiclient.exe to always run as administrator, it would not even load as the shell. With the AHK scripts, all my techniques either triggered UAC or would ask for administrator credentials. I think disabled UAC would allow this technique to work, but it would be much better if there were a way to avoid that.

[jfrsw]

It looks like directly modifying the global HKLM key is too hard to manage from Libki itself. To find out how to assign Libki as a shell for all users by other means, I tried a different approach. By using a policy setting (that could be set using a local or domain GPO), it's possible to assign a custom shell to the operating system user that will run Libki, without modifying the global HKLM shell key. That way, Libki will be started as the shell for that user as mandated by the GPO setting, and when it runs explorer.exe after a successful login, the whole desktop will be loaded, as the the global HKLM shell key will still be 'explorer.exe'. I tried it and it seems to work.

Unfortunately, that means that the Libki installer will not be able to set itself as a default shell for everyone, but the GPO method seems easy to apply, and the only modification needed on the installer is an option to not run libkiclient.exe automatically after loading explorer.exe and leave it to be run by other means (default shell via GPO, or whatever).

[kylemhall]

That's fantastic! Can you describe in more detail how to set this up? I'd love to add documentation for this method in the manual for less technically inclined users.

…

On Fri, Mar 6, 2020 at 4:59 AM jfrsw ***@***.***> wrote: It looks like directly modifying the global HKLM key is too hard to manage from Libki itself. To find out how to assign Libki as a shell for all users by other means, I tried a different approach. By using a policy setting (that could be set using a local or domain GPO), it's possible to assign a custom shell to the operating system user that will run Libki, without modifying the global HKLM shell key. That way, Libki will be started as the shell for that user as mandated by the GPO setting, and when it runs explorer.exe after a successful login, the whole desktop will be loaded, as the the global HKLM shell key will still be 'explorer.exe'. I tried it and it seems to work. Unfortunately, that means that the Libki installer will not be able to set itself as a default shell for everyone, but the GPO method seems easy to apply, and the only modification needed on the installer is an option to not run libkiclient.exe automatically after loading explorer.exe and leave it to be run by other means (default shell via GPO, or whatever). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#39?email_source=notifications&email_token=AAAMK2LBPCP3FJWKGHSI3M3RGDCORA5CNFSM4IXOYJBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOAY6LI#issuecomment-595693357>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMK2M67Q7THLF4JYKEFVTRGDCORANCNFSM4IXOYJBA> .

-- Kyle M. Hall Loose Cannon, ByWater Solutions kyle@bywatersolutions.com https://bywatersolutions.com <http://bywatersolutions.com/> *What is Koha? <http://bywatersolutions.com/what-is-koha/>*

[jfrsw]

I still have writing some more detail documentation on this configuration as a pending task. I could try to add it to the manual too... what section would be good to place it in?

[kylemhall]

@jfrsw I think a new section under Desktop Client / Windows would make sense. Thanks!