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

AppArmor on Torizon OS

Introduction​

AppArmor is a Linux Security Module (LSM) that implements Mandatory Access Control (MAC). The framework confines applications by enforcing per-program profiles that define which resources applications can access, such as files, executable paths, and network sockets. On Torizon OS, AppArmor can be used to add application-level confinement.

This article explains how to enable AppArmor on Torizon OS and highlights important usage considerations. For advanced use cases, refer to the AppArmor documentation.

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

Prerequisites​

  • A Toradex device with Torizon OS 7.7.0 or later installed
  • A configured TorizonCore Builder environment on the host machine, as described in the TorizonCore Builder documentation
info

The TorizonCore Builder environment is required to enable AppArmor for production workflows. For evaluation purposes, it is possible to enable AppArmor directly on the target device during runtime.

Enabling AppArmor on Torizon OS​

By default, AppArmor is disabled in Torizon OS and requires minimal configuration before it can be used. Enabling AppArmor can affect system behavior, including boot time, runtime overhead, and the default restrictions applied by loaded profiles. For this reason, enabling AppArmor should be a deliberate product-design decision.

Evaluation​

For evaluation purposes, AppArmor can be configured directly on a running target device without rebuilding the image. This configuration takes effect after the next reboot.

To enable AppArmor during runtime, add the security=apparmor Kernel command-line argument with the following command:

# sudo fw_setenv tdxargs security=apparmor
warning

The fw_setenv command modifies U-Boot environment variables. Before changing tdxargs, check the current value:

# sudo fw_printenv tdxargs

If tdxargs already contains other Kernel arguments, preserve the existing values and append the security=apparmor argument instead of overwriting the full variable.

After executing the command to enable AppArmor, reboot the device for the changes to take effect. After rebooting, verify that AppArmor is enabled by running the following command:

# aa-enabled
Yes

After confirming that AppArmor is enabled, AppArmor profiles can be created under /etc/apparmor.d/ on the target device.

To disable AppArmor, remove the security=apparmor argument from the tdxargs U-Boot environment variable and reboot the device:

# sudo fw_setenv tdxargs
warning

If tdxargs previously contained other Kernel arguments, ensure that the existing values are preserved when removing the security=apparmor argument.

After rebooting, verify that AppArmor is disabled by running the following command:

# aa-enabled
No - disabled at boot.

Production​

For production deployments, enable AppArmor by generating a custom Torizon OS image with TorizonCore Builder. This workflow uses TorizonCore Builder's support for customizing kernel arguments.

The following tcbuild.yaml example enables AppArmor by adding the security=apparmor Kernel command-line argument:

tcbuild.yaml
# Sample configuration file:
input:
  easy-installer:
    local: images/torizon-core-docker-colibri-imx6-Tezi_7.7.0+build.7.tar
customization:
  kernel:
    arguments:
      - security=apparmor
output:
  easy-installer:
    local: torizon-core-docker-colibri-imx6-Tezi_7.7.0.CUSTOM

Build and deploy the custom image with the TorizonCore Builder command as explained in the TorizonCore Builder documentation. The resulting image should have AppArmor enabled by default.

To confirm that AppArmor is running and enabled, run the following command on the target device:

# aa-enabled
Yes

The Effects of Enabling AppArmor​

Enabling AppArmor can affect system behavior. Review the following sections to understand the potential impacts of enabling AppArmor before deploying it in a production environment.

Boot Time​

Boot time may increase when AppArmor is enabled. The apparmor.service systemd service loads AppArmor profiles during system boot, which can add additional seconds to the boot process.

The added boot time depends on the number of profiles that must be loaded. In general, loading more profiles can increase boot time, while loading fewer profiles can reduce it. For products with strict boot-time requirements, measure the impact on the target device and final profile set.

Overhead​

AppArmor may introduce runtime overhead because access checks are enforced according to the loaded profiles. The impact depends on factors such as the workload, the target device, the number of loaded profiles, and the complexity of the profile rules.

In many use cases, the performance impact is expected to be small, approximately in the range of 3-5% of the total system resources. However, the exact impact depends on the application and profile design. Benchmark representative workloads on the target device before enabling AppArmor in production.

Default Profiles​

The most visible impact of enabling AppArmor may come from the default profiles that are loaded and enforced. Most of these profiles come from the standard AppArmor profile set. Torizon OS does not add custom Torizon-specific profiles by default because profile design is application-specific.

Default profiles can restrict certain actions and operations. For example, the following command attempts to search for the string torizon in the /etc/passwd file using zgrep. However, this operation is blocked by the default AppArmor profile for zgrep:

# sudo zgrep torizon /etc/passwd
/usr/bin/zgrep: line 254: /usr/bin/gzip: Permission denied
/usr/bin/zgrep: line 269: /usr/bin/grep: Permission denied

In this example, the operation is blocked even with sudo privileges, demonstrating the effect of the default AppArmor profile for zgrep.

To check which profiles are active, run the following command while AppArmor is enabled:

# sudo aa-status
apparmor module is loaded.
61 profiles are loaded.
61 profiles are in enforce mode.
   /usr/lib/apache2/mpm-prefork/apache2
   /usr/lib/apache2/mpm-prefork/apache2//DEFAULT_URI
   /usr/lib/apache2/mpm-prefork/apache2//HANDLING_UNTRUSTED_INPUT
   /usr/lib/apache2/mpm-prefork/apache2//phpsysinfo
   apache2
   apache2//DEFAULT_URI
   apache2//HANDLING_UNTRUSTED_INPUT
   apache2//phpsysinfo
   avahi-daemon
   dnsmasq
   dnsmasq//libvirt_leaseshelper
   docker-default
   dovecot
   dovecot-anvil
...
warning

Review the loaded profiles and test the application behavior to identify any potential issues that may arise from the default AppArmor profiles. Adjust or create custom profiles as necessary to ensure your application functions correctly while maintaining security.

Docker Profiles​

Docker integrates with AppArmor by applying profiles to containers. Custom profiles can be created to restrict operations inside a container, providing an additional layer of defense together with container isolation.

When AppArmor is enabled, Docker automatically generates and loads the default docker-default profile for containers. Containers use this profile by default unless another profile is specified with the --security-opt option.

Custom AppArmor profiles can also be created and applied to specific containers. For more information, refer to the Docker AppArmor documentation.

Send Feedback!