When using AppArmor, it is customary in 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 a 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 purpose, 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 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. - /etc/init.d/apparmor:
This tool allows to unload all policy with the teardown option, and to clear the policy cache with the clear option. Since this tool can disable AppArmor, it must be denied in the default profile, and not allowed in any of the other AppArmor profiles.deny /etc/init.d/apparmor wklx,