Last time we finalized the proper way to create a new desktop and launch our kiosk application into it. But we're not quite done with making a true kiosk application yet -- we still need to discuss security.
One assumption I'm going to make is that you're able to configure the machine in question which will run the kiosk application, and what's more, you can run as admin, and you are not running on a Home machine (you need a Pro or Server machine for the group policy editor, IIRC).
Steve brought up the first good point (which I happened to miss) in the second installment of the series: Ctrl+Alt+Del behavior is erratic. It turns out that if you have your logon settings set a specific way, you can get to the Ctrl+Alt+Del desktop even from your kiosk desktop. Since we don't want to rely on something as spurious as logon settings when it comes to security, let's talk about how to solve this issue.
The correct way to handle this is to disable specific buttons for the task manager. You do this with the group policy editor application that comes with windows (remember, we only care about versions of Windows which have desktop support, so NT and up).
Go to Start->Run and type gpedit.msc to enter the policy manager. If you go to User Configuration->System->Ctrl+Alt+Del Options, you'll see the list of options you can disable from that dialog.
However, you're unable to disable the Shutdown button from here -- it's actually stored in another location. Go to User Configuration->System->Start Menu and Taskbar->Remove and Prevent access to the Shutdown command.
The Ctrl+Alt+Del window isn't the only thing you want to restrict access to. Quite often, you don't want the user to be able to do much of anything. For instance, you don't want the user to be able to run arbitrary programs, because then they can start monkeying with things at will. Don't believe me? Try this trick:
- In your kiosk application, make a call to GetOpenFolderItem which is unfiltered.
- Run the kiosk app. Note that you can't shutdown if you hit Ctrl+Alt+Del (which is good).
- Click the button in your app to bring up the dialog.
- Navigate to your Windows directory, and find explorer.exe
- Right click on Explorer.exe and select Open
- Viola, instant security hole. The desktop, start menu and everything comes back. Oops!
- (You'll have to reboot, I believe, in order to get your kiosk desktop back to its blank state, so you may want to do that now).
So what other policies should we be editing? Well, to fix that hole, I would set User Configuration->Administrative Templates->Windows Components->Windows Explorer->Hide these specified drives in My Computer (and pick the installation directory or all drives, so the user can't get to anything in it), and Remove Windows Explorer's default context menu. That should fix the hole we just found, but there are other issues you may still want to work around. For instance, you can still get to the C: drive even though it's hidden by typing it into the editfield in the Open dialog! So you may also want to set Prevent access to drives from My Computer so that the sneaky will get a message telling them they can't do that.
There are a ton of different settings in the group policy editor that you can monkey around with to tweak the system to your exact needs. But I'm just going to touch on some of the more handy ones here instead of explaining them all to you.
- User Configuration->Administrative Templates->Start Menu and Taskbar->Remove Search menu from Start Menu
- User Configuration->Windows Components->Windows Explorer->Remove search button from Windows Explorer
- User Configuration->Administrative Templates->Control Panel->Show only specified Control Panel Applets (remove any or all)
- User Configuration->Administrative Templates->Windows Components->Windows Installer->Prevent removable media source for any install
- User Configuration->Administrative Templates->Network->Network Connections-> (lock down as much as you can here)
- User Configuration->Administrative Templates->System->Prevent Access to the command prompt
- User Configuration->Administrative Templates->System->Prevent Access to registry tools
- User Configuration->Administrative Templates->System->Turn off autoplay
- User Configuration->Windows Components->Internet Explorer->Browser Menus (disable as much as you can here)
- User Configuration->Windows Components->Internet Explorer->Disable auto complete for forms AND save passwords
Granted, there are a bunch of other options you can work with. But these are some of the major ones. Unfortunately, these settings will probably be different from kiosk to kiosk depending upon the application. What's more, these are administrative settings which need to be setup at install time. While most (all, possibly) of these settings reside somewhere in the registry, the only officially sanctioned way to set them is via the group policy editor. I would highly discourage you from trying to modify registry values for these settings because the registry keys may change from one version of Windows to the next (and it's very easy to miss a key if a particular option spans multiple keys). So my recommendation is to get your application working, and then do some real-world testing on a locked-down machine. Remember to think like a kid looking for loopholes -- that's how you'll find things you've missed. ;-)
In closing, a kiosk application is not as trivial as checking MenuBarVisible = false and FullScreen = true if you want to make it truly secure. However, it's also not that difficult (as we've seen) to do it right. You're welcome to use our KioskApplication class in any of your own projects, and can expect to see it arrive in the next version of the Windows Functionality Suite. Enjoy, and happy coding!
There -- an "exciting conclusion" or something. ;-)
Whew. You should make this into an article, with example project, etc., on RBLibrary.
Aaron, can you please explain why there's a need to make our own desktop and running our application on it when we can configure all security aspects on the Group Policy?
There's even a policy (Custom user interface) on Group Policy (User Configuration/Administrative Templates/System/) that allows you to change the default Windows' shell (Explorer) to anything you want, and it could be for example the kiosk application. I never tested this, but from what I read it seems that when we enable this policy and configure it for other application, Windows will boot into this application upon startup without anything else running: no desktop environment, no start menu, no taskbar etc.
@Carlos: I don't much feel like trying this without knowing.
Assuming a standalone XP pro machine with its own group policy. If I change the Windows Shell to mySpiffyApp.exe, will I have a way to get at the policy editor to change it back when I no longer need the machine to be a kiosk?
@Carlos -- Making your own desktop gives you a lot more control over having a secure environment, but it is not strictly required. For instance, with this scenario, you can use a remote desktop connection to connect into the default desktop and control the environment without having to physically be at the machine and reboot it, etc.
As for replacing the shell, I've heard of such a thing, but there's very little information about what that means exactly. For instance, if you replace the shell, what functionality do you automatically lose? Common dialog boxes perhaps? I really don't have enough information to recommend or dissuade people from doing that one.
I just got a chance to check your blog today for the first time in several days, and saw this series. It's very timely for me, because I'm working on an app that needs kiosk-like abilities.
So, this is going to be GREATLY helpful.
But, since my app is cross-platform for Windows and OS X, how do I achieve similar levels of kiosk behavior under OS X? :
@Steve: You should be very carefull with that, as I think that anything you change on a *local* Group Policy with gpedit will affect all users, including administrators.
There is one trick that allows you to change a local Group Policy in a way that do not affects administrators, but be carefull - here's one that I found on Microsoft:
http://www.microsoft.com/technet/prodtechnol/Windows2000Pro/reskit/part3/proch07.mspx?mfr=true
Security Considerations
Local Group Policy does not allow you to apply security filters or to have multiple sets of Group Policy objects, unlike Active Directory–based Group Policy objects. You can, however, set Discretionary Access Control Lists (DACLs) on the %systemroot%\System32\GroupPolicy folder so that specified groups are either affected or are not affected by the settings contained within the local Group Policy object. This option is useful if you have to control and administer computers that are used in situations such as kiosk environments, where the computer is not connected to a local area network (LAN). Unlike Group Policy administered from Active Directory, the local Group Policy object uses only the Read attribute, which makes it possible for the local Group Policy object to affect ordinary users but not local administrators. The local administrator can first set the policy settings he or she wants and then set the DACLs to the local Group Policy object directory so that administrators as a group no longer have Read access. For the administrator to make subsequent changes to the local Group Policy object, he or she must first take ownership of the directory to give him or herself Read access, make the changes, and then remove Read access.
Important After you make changes to the Group Policy object, remember to remove Read access for the group in which you are a member. If you fail to remove Read access, it can be difficult, if not impossible, to gain access to the Group Policy object.
It's also possible to change almost everything you setup with gpedit directly on the registry for a specific user, but that's time consuming. Here's a page with the registry keys used in Group Policy:
http://www.j79zlr.com/gphome.php
You might be interested in looking this:
Shared Computer Toolkit for Windows XP
http://www.microsoft.com/windowsxp/sharedaccess/overview.mspx
Found also this that might help:
INF: How to Protect Windows NT Desktops in Public Areas
http://support.microsoft.com/?kbid=143164
@Aaron: But if the machine belongs to an Active Directory domain aren't you able to do almost anything remotely (including shut it down) without that scenario too?
About replacing the shell: I don't know if it looses or not any functionality as I didn't test it, but all papers I found at Microsoft about setting up a kiosk with just Internet Explorer, said to configure "Custom user interface" with IE.
I found this document that talks about implementing kiosk applications, that might be useful to someone, where they also recommend to replace the shell with the kiosk application (IE or any other):
Implementing Common Desktop Management Scenarios with the Group Policy Management Console
http://technet2.microsoft.com/WindowsServer/en/Library/542e1cb5-2dd8-4401-95fe-09dc557ca3191033.mspx?mfr=true
Group Policy Common Scenarios Using GPMC
http://www.microsoft.com/downloads/details.aspx?familyid=354b9f45-8aa6-4775-9208-c681a7043292&displaylang=en
Replacing explorer.exe with your kiosk application is a viable solution. If you didn't disable the taskmanager, you can start explorer.exe again. Win + L also works, allowing you to switch to another user. If you have disabled all this, make sure your kiosk application can set the shell to explorer.exe again. A reboot will then bring up your normal windows again.
Was anyone able to prevent the admin from using the group policy? I am trying to set up a custom user interface for non-admins(XP Pro, no active directory). I tried using cacls as described in the Microsoft page Carlos mentioned but the admin account still is picking up the custom user interface setting. Any ideas? What should the permissions look like on the group policy folder?