Managing Mac Kiosks

Managing Mac Kiosks

Overview


We have implemented multiple forms of kiosk throughout the years at the Marriott Library or other locations on campus that we support. Initially, we implemented web kiosks that provided anonymous users at the Marriott Library quick access to limited library & campus resources like the catalog system, databases, etc. These web kiosks needed to be secure, resilient and easy to use for the public but at the same time prevent anonymous access to resources we do not allow. This expanded to “exhibit” kiosks that would include media content like audio, video and other types of content focused around a specific library exhibits.

And finally, we have implemented “Digital Displays” which use technologies such as LCD, LED and projection to display digital images, video, web pages, or text. They can be found in public spaces of the Marriott Library to provide wayfinding, exhibitions and marketing & communication information including text, animated or video messages for advertising, information, entertainment and merchandising to campus students, staff and faculty.

This post will cover a history of the methodologies & technologies we have implemented and modifications we have developed to address IT development & resource impact and ease access to outside groups like web development & content providers.

History


Starting around 2004, we implemented public web kiosks using Mac OS X. On a standard Mac OS X system, users have greater overall access to the operating system features. They can run the Finder, use the Dock, launch most applications, and save files in their home folder. On our public web kiosks, however, are significantly more “restrictive”, limiting users’ access to just a few applications. The available applications are confined to a small subset like a web browser, utilities, and helper applications. The kiosks themselves have been set up to be extremely easy to use, capable of operating relatively unattended, require minimal maintenance, and are easy to update. Their key operating feature is the ability to restrict users from making changes to the system or hard disk.

   

This is a list of the key modifications we made to set up our kiosks originally:

  • Guest User – a new user that does NOT have administrative rights to the machine and that has a REAL password
  • Limit Write Access – limit what a guest user can change on the hard disk by changing file permissions and ownership
  • Enable Firmware Security – prevents users from making changes to the OS by bypassing default startup disk.
  • Customized Apple Menu – using third party applications such as Fruit Menu, the Apple Menu can be customized to remove shutdown/logout options and prevent users from shutting down or logging out of the Mac
  • Administrative Utility – to allow administrative users to perform some admin procedures like restarting, shutting down, logging out, launching the Finder, but restrict these processes from the general kiosk user, we created an application which requires a password to access to these functions
  • Replace the Finder – Many kiosks only allow users to use one application, such as a web browser. To do this, you will need to replace the Finder with the desired application by either changing the loginwindow preferences or swapping the Finder with another application
  • Disable the Dock – disabling the Dock.app by renaming it, or changing the permissions prevents users from launching the it. It also creates more usable screen space on your kiosk machines
  • Maintenance – to clean up these changes, use a script that runs at login, logout, a defined schedule, or when the machine is idle.

The public kiosks refreshed based on maintenance schedule and activation of screensaver and would restore the kiosk users home folder to a default including browser settings, bookmarks, default home page, etc. We restricted web content using open source software called “Privoxy“. Privoxy is a non-caching web proxy with advanced filtering capabilities for enhancing privacy, modifying web page data and HTTP headers, controlling access, and removing ads and other obnoxious Internet junk. Privoxy has a flexible configuration and can be customized to suit individual needs and tastes.

Whitelist
We use Privoxy to give access to specific sites using a defined whitelist and block all other websites.

Image result for whitelist

Then we provide the user with feedback regarding blocked web sites. If they user needs to access restricted web sites, we direct users to a non-kiosk system, one requiring an authenticated login to access those sites.

Proxy Configuration & Bypass
We set the kiosks to use they proxy by programmatically modifying the System Preferences -> Network -> Proxies Settings to set and specify the proxy settings and can exclude sites from the proxy that don’t work properly with a proxy or specifically with Privoxy.

We have an old perl script that we use to manage the proxy configuration which uses the networksetup command line utility with these commands:

  • networksetup -setwebproxy networkservice domain portnumber authenticated username password
  • networksetup -setsecurewebproxy networkservice domain portnumber authenticated username password
  • networksetup -setproxybypassdomains networkservice domain1 [domain2] [...]

For example here is the proxy perl script:

While this method was effective for many years, other backend code and configuration maintenance made supporting new operating system versions and Safari browser updates more and more difficult. And with increasing demands, projects & priorities on our IT group it was decided to move to a commercial application called, xStand.

xStand allowed us to restrict access to some web sites, the operating system, system settings, the downloading of files and applications with little additional development and free up our time from continually updating our previously internally  developed public web kiosk scripts & configuration. It had a few minor issues and annoyances, but overall worked well for our needs.

Unfortunately, after many years of solid service, the company supporting xStand closed its doors and sold the software to another developer and then their license servers were decommissioned that prevented the software from running properly and displayed the following message:

We tried working with the “new” company, Noblic Inc., but found their customer support and server licensing less than desired. We began implementing an internal solution, one designed to require much less maintenance and effort integrating new operating system versions and browser updates.

For example, this FAQ was posted to the NobKiosk, but as of now has been removed. Note “If you have a license of xStand, you can continue using it for free until end of 2018” wasn’t held up in our experience.

As the posting of this article xStand is still available via the Mac App Store, but is no longer supported or in development by the original developers, adnX SARL.

Brave New World


Our kiosk implementation leverages WordPress to provide our content creators, primarily the libraries marketing and communications group, with tools they are already familiar with. As you will see, this approach offers a high degree of control and customization.

With the WordPress site, we implemented the plugin called LayerSlider that allows easily editing pages, animations & effects used on our digital displays and other WordPress sites.

  • LayerSlider – Digital Display Settings Example

  • LayerSlider – Editing Digital Display Slides Example



  • LayerSlider – Digital Display Animation Options Example

Hide Mouse Cursor
We also implemented the following Cascading Style Sheets (CSS) to hide the mouse cursor:

Another option on Mac systems is using Cursorcerer Preference Pane which allows you to which allows you to hide the cursor at any time by use of a global hotkey or based on idle time and bring it back as soon as you move the mouse. For our digital displays setup we thought it would be better to go the CSS route vs installing additional software to give us this functionality. But, for other scenarios like a media server, Cursorcerer might meet your needs if you can’t depend on CSS.

Manage Display Settings
To manage the display preferences on our Mac systems, we developed the python script/library named Display Manager and made it available to others on our GitHub repository. It allows users to programmatically manage Mac system display settings like resolution, refresh rate, rotation, brightness, screen mirroring, and HDMI underscan. It’s primarily intended for Mac Admins who need to control displays in specific, predictable ways. Display Manager works in a 2-part package: a library that actually controls Mac displays ( display_manager_lib.py), and a script that allows access via the command line, and executes commands in a non-interfering way ( display_manager.py).

On our digital display implementation, we set the resolution, rotate the display 90 degrees and set the HDMI underscan to properly fill the display.

For example, we use Jamf Pro and scope our digital display to a policy that runs a shell script with parameter values.

Using the following script:


And run it ongoing at every login and via custom trigger to allow easy ad-hoc execution to set display settings.

If your environment isn’t using Jamf Pro, you could easily use a similar methodology with tools like Outset or custom launch item to run based on your environment needs.

 

Google Chrome Command Line Switches

We decided to use Google Chrome for our browser kiosk implementation using Chromimum command line switches.

Using the this command format:


We used the following switches:

  • --kiosk
    Enable kiosk mode with Google Chrome in full screen.

    /path/to/Google Chrome.app/Contents/Google Chrome --kiosk


  • --kiosk [WEB_ADDRESS]
    Enable kiosk mode with Google Chrome in full screen with specific web site.

    /path/to/Google Chrome.app/Contents/Google Chrome --kiosk https://lib.utah.edu

    • --app=[WEB ADDRESS]
      Specifies that Google Chrome should be launched in “application” mode without address bar.

      /path/to/Google Chrome.app/Contents/Google Chrome --kiosk --app=https://lib.utah.edu

 

  • --force-first-run
    Displays the First Run experience when the browser is started, regardless of whether or not it’s actually the First Run (this overrides kNoFirstRun).

Process Overview
Here is an overview of how the various pieces of our kiosk system work together:

Script
Here is the python script we are using with our kiosk implementation. It launches Google Chrome based on command line switched based via configuration property list, then uses AppleScript to verify its the frontmost application, verifies if screen saver is running using pgrep, uses ioreg to verify is display is asleep,  removes Google Chrome profile to cleanup previous user session,  and based on conditions will restart Google Chrome if necessary like if it has crashed, quit by user or if screen saver activated or display asleep, etc.

With the following LaunchAgent:

This LaunchAgent sends standard output to /tmp/chrome_kiosk.log , standard error to /tmp/chrome_kiosk.log , will keep alive if the script fails and is limited to Aqua session.

Apple Technical Note named “Daemons and Agents” that explains most of the session types available for launchd.

  • Aqua – GUI agent which has access to all the GUI services
  • LoginWindow –  Pre-login agent which runs in the login window context
  • Background –  Runs in the parent context of the user
  • StandardIO – Runs only in non-GUI login session (i.e SSH sessions)

A useful GUI application that allows you to create, manage, debug & learning system and user services & options on Mac systems is named, LaunchControl.

The property list that is used to define individual kiosk configurations either can be customized using the  defaults command or a configuration profile:

Which we store on our kiosks at the following location:

/Library/Management/edu.utah.mlib.kiosk.settings.plist

Future


In the future we we might migrate from Privoxy to EZProxy after it has been thoroughly tested and staged. We are currently using EZproxy to provide access from outside our library’s network to restricted-access websites that authenticate users by IP address and if it will give us similar functionality as Privoxy with our kiosk implementation would lessen the amount of proxy services we are supporting.

If there is interest by the community in our kiosk methodology and code, we will clean it up and make it more community friendly and post to our public GitHub repository. Let us know by using our contact us page or post a comment to this blog post.

No Comments

Leave a Reply