Enable AppArmor for Supervisor in devcontainers

[agners]

Summary

Enable AppArmor support in devcontainers so apps developers can develop and test AppArmor profiles for their apps.

• Add mount-securityfs.service to mount securityfs inside the container (the kernel doesn't do this automatically in containers). A regular systemd .mount unit cannot be used here because systemd refuses to manage mount units for API filesystem paths like /sys/kernel/security.

  $ systemctl status sys-kernel-security.mount
    ○ sys-kernel-security.mount - Mount securityfs for AppArmor
         Loaded: bad-setting (Reason: Unit sys-kernel-security.mount has a bad unit file setting.)
         Active: inactive (dead)
          Where: /sys/kernel/security
           What: securityfs
  

• Add hassio-apparmor.service and loader script to download and load the hassio-supervisor AppArmor profile on first boot

• Install apparmor package in both devcontainer images

• Switch supervisor_run from apparmor=unconfined to apparmor=hassio-supervisor

Notes

• Both systemd services use ConditionSecurity=apparmor to gracefully skip on hosts without AppArmor kernel support.

• Tested on a host without AppArmor: Docker's --security-opt apparmor=hassio-supervisor does not cause a failure when the kernel has no AppArmor support, so supervisor_run still works. Supervsior simply detects AppArmor is missing:

  2026-04-14 09:58:23.501 WARNING (MainThread) [supervisor.host.apparmor] AppArmor is not enabled on host
  

• auditd does not work inside the container due to missing permissions on the kernel audit subsystem (audit is host-global and cannot be controlled from within a container). AppArmor denials are still logged to the kernel ring buffer and visible via dmesg or journalctl -k. For full audit logging, run auditd on the host OS directly.

Fixes: #157

[sairon]

Looks good both with AA enabled and with unloaded kernel module on a Linux host, so 👍