Kiosk-shell escape on Linux self-service terminals

1. Mechanism

A kiosk shell on Linux is built from a small stack: a display manager configured to auto-login a kiosk user, a window manager or compositor configured to run only the payment application, and a session that has the desktop environment, taskbar, and shell escapes disabled [1]. Distributions ship kiosk-mode session configurations; vendors customise them; deployments ship the result.

The shell’s job is to enclose the citizen-facing UI. Escape classes the field has documented:

• Keyboard chords. Ctrl+Alt+F1–F6 switch virtual consoles. Super opens an activities overview on some desktops. Custom key combinations bound to scripts.
• USB hotplug. A plugged-in USB keyboard, storage device, or HID device that the kiosk’s udev rules accept can introduce inputs the kiosk did not sanitise.
• File-manager dialog. A select-receipt-PDF dialog or similar that opens a file chooser exposes the filesystem navigator — and from there, any file the kiosk user has permission to read.
• Accessibility shortcuts. Screen reader, on-screen keyboard, and other a11y features come bound to platform shortcuts. They sit behind the kiosk’s input filter; many shells forget to disable them.
• Recovery boot. Power-cycling and pressing a recovery shortcut at boot enters a rescue or installation environment. The kiosk shell does not exist there.
• SysRq / kernel panic keys [2]. The Linux kernel exposes Magic SysRq keypresses for low-level operations. Disabled by configuration; enabled by default on some distributions.

2. Where in the runtime it operates

The shell’s enforcement happens at three layers:

• Display server. The X server or Wayland compositor decides which clients can connect and which inputs are delivered to which window.
• Session manager. systemd / SysV init decides what processes the kiosk user runs.
• Kernel. Decides which input events the userspace ever sees. SysRq, console switching, and recovery-shortcut binding live here.

A successful escape can land at any layer. Once outside the shell, the attacker has whatever capability the kiosk user holds — frequently more than the shell suggested.

3. Which checkpoints it bypasses

• Country-specific SST certification. Several jurisdictions define what the certified application must do — for example, in Germany the girocard Technische Anlage maintained by Deutsche Kreditwirtschaft [5] for terminal acceptance, and BSI Common Criteria Protection Profiles for ATMs (the BSI-CC-PP family) [6] for ATM-class hardware. (TR-03124 is a separate BSI guideline scoped to eID-client implementation, not to ATM/SST.) For SST and banking-kiosk certification in India, the Reserve Bank of India and NPCI publish channel-specific guidelines for UPI, AEPS, and ATM deployments. PCI PTS POI is a global certification regime (not EU-specific) that applies to terminal hardware deployed across most jurisdictions, including EU member states. The certification scopes the application; an escape from the application’s enclosure exits the certified runtime.
• PCI PTS. Applies to the cardholder-data path; the cardholder-data path is preserved if the attacker exits the shell but does not touch the SCR.
• EMV credential authentication. Unaffected — credentials are still validated at the rail.

4. Which signals make it observable

runtime.environment. SSTs typically expose no remote attestation channel comparable to Play Integrity or App Attest; the substrate is often the only signed-evidence surface the operator has. What the Trusted Runtime Primitive can observe depends on the display server:

• On X11. The currently focused window’s process and class is observable via root-window properties (_NET_ACTIVE_WINDOW) — when the payment application loses focus to a non-shell process, the substrate signs the moment.
• On Wayland. Wayland’s security model denies clients visibility into other clients’ focus state without privileged compositor cooperation. Focus-loss observation requires either a custom compositor that exports a focus signal to the payment app, a wlr-foreign-toplevel-management extension on wlroots-based compositors, or process-tree monitoring via /proc as a fallback.
• Across both. Connected USB devices and their classes (HID keyboard, storage, etc.) with hotplug timing via udev/sysfs. The kernel’s SysRq enable state (/proc/sys/kernel/sysrq) and configured console-switching policy. The user-session boundary — when a process outside the payment app’s tree starts under the kiosk user — observable via /proc walk under the kiosk UID.

5. Evidence Token shape when observed

The following example is illustrative; field names, type values, and schema are defined in YEI-001 §4 (available through the spec-access process).

{
  "ev": [{
    "ts":   "2026-06-15T10:23:14Z",
    "class": "runtime.environment",
    "type":  "kiosk.boundary_event",
    "data": {
      "event":             "focus_lost_to_non_shell",
      "current_process":   "/usr/bin/xterm",
      "during":            "transaction_active",
      "usb_devices_count": 3,
      "sysrq_enabled":     true
    }
  }]
}

The signal supports both runtime detection (the operator can freeze a transaction in progress when focus leaves the application — subject to the X11 / Wayland observability constraints in §4) and post-hoc audit. On SSTs that expose no remote attestation channel of their own, this signed channel is what Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments — contributes to the operator’s audit story.

6. Cross-references

• Sibling articles: pos-tampering, os-downgrade-attacks, attestation-drift-distributed-fleets
• Site: /sst — SST deployment surface

7. External references

[1] GNOME. GNOME Kiosk — single-application session for kiosk deployments. gitlab.gnome.org/GNOME/gnome-kiosk. Cited 2026-03-02.

[2] Linux Kernel Documentation. Magic SysRq key. docs.kernel.org/admin-guide/sysrq.html. Cited 2026-03-02.

[3] Wayland. Protocol documentation (security model and seat handling). wayland.freedesktop.org/docs/html. Cited 2026-03-02.

[4] wlroots. wlr-foreign-toplevel-management-unstable-v1 — protocol for privileged compositor extensions exposing other clients’ window/focus state. wayland.app/protocols/wlr-foreign-toplevel-management-unstable-v1. Cited 2026-03-02.

[5] Deutsche Kreditwirtschaft. girocard Technische Anlage (TA) — terminal specifications. bezahlen-mit-karte.de/girocard.html. Cited 2026-03-02.

[6] BSI. Common Criteria Protection Profiles for ATMs (BSI-CC-PP family). bsi.bund.de/EN/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Zertifizierung-und-Anerkennung/Zertifizierung-von-Produkten/Schutzprofile. Cited 2026-03-02.