Kernel Configuration Hardening

Introduction

Kernel command-line options and kernel sysctl settings are useful production hardening: they limit what local processes can learn from the kernel, and they control USB behavior that development images leave open for convenience. Command-line changes require a reboot. Sysctl settings can be applied at runtime through /etc/sysctl.d/ and captured into a custom image with TorizonCore Builder.

IPv4 and IPv6 network sysctls are covered in Network Hardening.

This article is part of the Production Hardening Checklist, which also explains how to persist these changes across a fleet.

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

USB Device Authorization

Physical USB access can introduce unexpected devices, whether through a rogue human interface device, malicious storage, or BadUSB-style firmware. On stock Torizon OS, new devices are authorized automatically, because usbcore.authorized_default is set to -1. Setting usbcore.authorized_default=0 on the kernel command line makes the kernel refuse every device until userspace explicitly authorizes it.

Setting this hardening option is very useful for devices where there may be unauthorized physical access to USB ports. It also requires careful discipline with udev rules; consider the trade-offs carefully before enabling it.

The trade-offs are:

Setting authorized_default=0	Leaving the stock default
Unauthorized USB devices never configure, which is a strong defense against unexpected USB peripherals	Any device that is plugged in works immediately, which suits a lab and is usually broader than you want in production
Requires an allow-list, maintained through udev rules, for every device you need	No allow-list engineering cost
Easy to break carrier hubs, USB Wi-Fi or WWAN adapters, keyboards, or Lockbox media if you do not test carefully	Nothing stops working unexpectedly after hardening
Pairs well with masking usermount when the product needs no removable media, as covered in systemd Service Hardening	Removable media and USB gadget workflows keep working without extra rules

Add the option to the kernel command line with TorizonCore Builder, which appends to the default arguments of the image:

# tcbuild.yaml
customization:
  kernel:
    arguments:
      - usbcore.authorized_default=0

See Customizing Kernel Arguments in Torizon OS for the full workflow.

Then authorize only the devices you need from userspace, typically through udev rules that match idVendor, idProduct, and device class.

caution

Onboard buses from your carrier board can often expose Wi-Fi, Bluetooth, hubs, and other peripherals as USB devices. Locking down authorization without allow-listing those can disable interfaces you still need.

Designing a full allow-list, including enumeration order, matching by class against matching by identity, and interface-level authorization, is beyond the scope of this article. The following references are useful starting points:

• Linux USB authorization, the kernel interface behind authorized and authorized_default
• Allow only known USB devices, practical udev allow-list patterns

Disabling debugfs

The debugfs filesystem exposes a wide set of kernel debugging interfaces under /sys/kernel/debug. It is mounted by default in Torizon OS. Unprivileged users cannot list it by default, but processes with sufficient privileges can. Production devices rarely need it.

Add the option through TorizonCore Builder:

# tcbuild.yaml
customization:
  kernel:
    arguments:
      - debugfs=off

After the device reboots, confirm that it is no longer mounted. The following command produces no output:

# mount | grep debugfs

Kernel Sysctls

On Torizon OS by default, unprivileged users can read the kernel log, because kernel.dmesg_restrict is 0. Pointer and performance-event restrictions also sit below a typical hardened baseline. These sysctls reduce local information leaks that are useful for developing an exploit.

Sysctl	Stock value	Hardened value	Why
kernel.dmesg_restrict	0	1	Blocks unprivileged access to the kernel log
kernel.kptr_restrict	0	2	Hides kernel symbol addresses from all users

Create /etc/sysctl.d/30-kernel-hardening.conf with the following contents:

kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2

Apply it:

# sudo sysctl --system

Verify the values, then confirm the effect. As an unprivileged user, dmesg now fails with Operation not permitted:

# sysctl kernel.dmesg_restrict kernel.kptr_restrict kernel.perf_event_paranoid
# dmesg