When using AppArmor, it is customary in the development phase to leave in place access to some features that are very useful, but that would jeopardize the system in production and would leave it vulnerable to certain types of attacks. With AppArmor on RDK, we’ve identified the following features that should be left in place for development, but removed for production.
In RDK, the default profile enables wide access by default, denying access to only specific files and paths. Therefore, the default profile is the one that needs some hardening for production purposes, since in all other profiles everything that is not explicitly allowed is denied.
remount capability
In most recent TVs/Set-Top Boxes, the storage device holding the root filesystem is some kind of eMMC, with some version of the Linux extfs on top of it, mounted as read-only. This makes for an efficient system with large storage space. However, it is inherently writable if you can remount it as read-write, instead of read-only.
While in the development phase there are many cases when you need to remount your root filesystem as read-write, it must be prevented for production, otherwise anyone who compromises the system could completely alter any and all files that are supposed to be read-only, and even disable AppArmor — by switching the enforce mode to complain mode in /etc/apparmor/apparmor_defaults.
Therefore, the remount capability must be removed from the default profile, and not added to any of the other AppArmor profiles.
# Remove 'remount' from the capability list in the default profile.
# Production capability list (remount removed):
capability,
network,
mount, umount, pivot_root,
ptrace, signal, dbus, unix,/etc/init.d/apparmor
This tool allows unloading all policy with the teardown option, and clearing the policy cache with the clear option. Since this tool can effectively disable AppArmor, it must be denied in the default profile and not allowed in any of the other AppArmor profiles.
# Add to the deny section of the default profile:
deny /etc/init.d/apparmor wklx,apparmor_parser
The apparmor_parser tool allows loading and replacing AppArmor policies at runtime. An attacker with access to this tool can load a permissive policy and effectively bypass all restrictions. This must be denied in production.
deny /sbin/apparmor_parser wklx,aa-disable, aa-complain, aa-enforce
These tools change the enforcement mode of AppArmor profiles. Access to them in production would allow switching any profile to complain mode — which logs violations but does not enforce them — undermining the entire MAC security posture of the device.
deny /usr/sbin/aa-disable wklx,
deny /usr/sbin/aa-complain wklx,
deny /usr/sbin/aa-enforce wklx,Note: All of these deny rules should be applied to the
defaultAppArmor profile only. All other RDK AppArmor profiles already operate in whitelist mode — so anything not explicitly permitted is already denied, including access to these AppArmor management tools.
Complete Production Hardening Additions
Putting it all together — the complete set of changes to the default AppArmor profile for production hardening:
# Production hardening additions to the default AppArmor profile
# Herve Jourdain, Ryvr Tech Ltd, 2023/07/13
#
# 1. Remove 'remount' from the capability list in the default profile
# 2. Add the following deny rules to the default profile:
# Deny access to AppArmor init script (can teardown/clear policy)
deny /etc/init.d/apparmor wklx,
# Deny access to apparmor_parser (can load/replace policies)
deny /sbin/apparmor_parser wklx,
# Deny access to profile mode-switching tools
deny /usr/sbin/aa-disable wklx,
deny /usr/sbin/aa-complain wklx,
deny /usr/sbin/aa-enforce wklx,With these additions, even a compromised process running under the default profile cannot disable or circumvent the MAC framework. Combined with removing the remount capability, this significantly raises the security bar for attackers attempting to achieve persistence on production TV or STB devices.