Skip to main content
Version: Torizon OS 7.x.y

Production Hardening Checklist

Introduction​

A default Torizon OS image is built for development. It advertises itself on the local network over multicast DNS (mDNS), accepts SSH connections on every interface, ships a torizon user account that belongs to the docker group, and leaves kernel debugging interfaces available. Defaults like that are in place to make the development experience smooth, but many of them are not appropriate for a production environment. This article describes the most common things users need to change when moving from a development device to a production-ready deployment.

Use this checklist as a pre-release gate: work through it before you promote an image to production. Each section below summarizes the decisions for one area and links to an article that explains the reasoning, the commands or instructions to enable/disable the related security features, and the trade-offs each one entails.

Hardening is a set of product decisions rather than a fixed configuration. Everything in this list should be understood as a recommendation that may or may not apply, depending on your own device and its security needs. You should read the recommendation, and then make and record your decisions about each one, rather than just blindly applying all of them. The correct answer for whether to implement a particular security measure always depends on your product's deployment context, threat model, and intended and reasonably foreseeable uses. Where a security hardening recommendation does not apply to your product, record why.

This article complies with the Typographic Conventions for the Toradex Documentation.

caution

Working through these items reduces the attack surface of a Torizon OS device. By itself, this guide does not satisfy certification schemes such as IEC 62443 or the EU Cyber Resilience Act. However, it can be a useful input to your CRA technical file, or other compliance documentation. Treat it as engineering groundwork that a formal assessment can build on.

Prerequisites​

  • A Toradex System on Module (SoM) running Torizon OS 7.
  • A reference device you can reach over SSH or a serial console.
  • TorizonCore Builder installed for rolling changes out to a fleet.
  • For the Secure Boot items, a Yocto build environment, because signed images are produced from source rather than with TorizonCore Builder.

Applying and Persisting Changes​

The articles in this section show commands that change the running system so that you can test a setting before you commit to it. Runtime changes are a validation tool, not a deployment mechanism.

To roll a policy out to a fleet, apply it on a single reference board, capture the resulting /etc changes with TorizonCore Builder, and merge them into a custom image. Run the capture from your host computer:

$ torizoncore-builder isolate --remote-host <device-ip> --remote-username torizon --changes-directory changes-hardening

Then reference the captured directory from your tcbuild.yaml:

customization:
  filesystem:
    - changes-hardening/

For the full procedure, see Capturing Changes in the Configuration of a Board on Torizon OS.

warning

When you enable root filesystem protection (ECoT), /etc becomes an in-memory overlay over the pristine /usr/etc from the image, so anything written there at runtime is discarded on reboot. That includes sysctl drop-ins, logind drop-ins, and the symlinks that systemctl mask creates.

On such images, most of the changes in this checklist must be built into the image rather than applied on the device, and files that genuinely need to persist must be relocated outside /etc. See Root Filesystem Protection on Torizon OS before you plan your hardening rollout.

Network​

See Network Hardening for the reasoning and the commands.

  • Listening socket audit is clean, with no unexpected TCP or UDP listeners. Ports published by containers count as well, so cross-check against Container Security.
  • Avahi and mDNS masked on production images, or a recorded reason to keep them.
  • IPv6 policy decided: disabled if the deployment is genuinely IPv4-only, otherwise IPv6 included in the listener audit.
  • Network sysctl hardening applied: IPv4 redirects and rp_filter=2; IPv6 sysctls as well if IPv6 stays enabled.
  • sshd.socket masked, with Torizon Remote Access provisioned and tested as the break-glass path first.

Kernel​

See Kernel Configuration Hardening for the reasoning and the commands.

  • usbcore.authorized_default=0 set on the kernel command line, with a device allow-list tested on real hardware.
  • debugfs=off set on the kernel command line.
  • Kernel sysctl hardening applied: kernel.dmesg_restrict, kernel.kptr_restrict, and kernel.perf_event_paranoid.

Filesystem​

See Filesystem Hardening for the reasoning and the commands.

  • /tmp is a tmpfs mounted nosuid,nodev, which is the stock default. Add noexec only after testing that your application stack tolerates it.
  • /var, and /data if your product uses one, mounted nosuid,nodev,noexec. Test Compose volumes and any host tools that need to run binaries from those paths.
  • Applications write only to /var and /data, leaving /usr immutable under OSTree.
  • Root filesystem integrity provided by torizon-signed and composefs rather than dm-verity.
  • Data partition encrypted with dm-crypt, where your threat model includes physical access to the storage medium.

Boot and Hardware​

See Boot and Hardware Hardening for the reasoning and the commands.

  • Secure Boot and U-Boot hardening in place through meta-toradex-security and torizon-signed, using production signing keys and burned fuses.
  • Serial UART getty masked. The unit name is board-specific.
  • Virtual console getty masked, with NAutoVTs=0 and ReserveVT=0 set in a logind drop-in.
  • If Secure Boot is not viable for the product, the fallback U-Boot console lockdown applied and its limitations recorded.

Accounts​

See Account and Access Hardening for the reasoning and the commands.

  • torizon password locked, or a recorded console password policy combined with a masked SSH listener.
  • torizon removed from the docker group.
  • sudo policy audited, with no NOPASSWD: ALL rule.
  • Root password authentication still disabled.
  • Accounts created during bring-up, or by vendor tooling, removed or locked.

systemd Services​

See systemd Service Hardening for the reasoning and the commands.

  • Stock units reviewed against the per-unit guidance, and the ones your product does not need masked.
  • usermount and udisks2 policy decided: masked unless the product needs Lockboxes or removable media.

Containers​

See Container Security on Torizon OS for the reasoning and the commands.

  • No privileged: true on any Compose service.
  • Containers run as a non-root user, set through Compose or the Dockerfile.
  • cap_drop: [ALL] with a minimal cap_add, plus no-new-privileges:true.
  • read_only: true wherever the workload allows it, with tightly scoped volumes and bind mounts.
  • Published ports minimized, or bound to a specific host address instead of every interface.
  • Compose files canonicalized so that all images are referenced by digest.

Logging and Observability​

See Logging and Observability for the reasoning and the commands.

  • Device monitoring left enabled, unless the fleet deliberately does not use it.
  • Off-box log forwarding decision recorded, with the bandwidth and data-sensitivity trade-offs weighed.
Send Feedback!