Premium App data protection in RDK using AppArmor

While RDK6 will be moving to containers to host the Premium Apps, running the Premium Apps with their own user instead of running as root is also a valid option, if its data can be protected.

While setting the permissions strictly to allow only the Premium App user to access its data, Linux permissions are based on DAC (Discretionary Access Control) policy, and therefore any application running as root, or any user logged in as root — through ssh or console — can circumvent the protection and access those data.

With a MAC (Mandatory Access Control) policy, this is preventable, therefore guaranteeing a much better level of security and confidentiality.

Introduction

There are several MAC frameworks available for Linux, like SELinux or AppArmor. In the case of RDK, AppArmor was selected as the MAC framework of choice.

The critical distinction: with DAC, root can always override file ownership restrictions. With AppArmor in enforce mode (MAC), even the root user is constrained by the active security policy — making it the right tool for protecting Premium App data on shared platforms where WPEFramework launches multiple apps under the same binary.

The Default Profile

The default profile provides the foundation for all RDK processes. Here is the version with Premium App data protection added:

# Default profile based on the one in meta-cmf-video,
# with changes to deny access to AmazonPrime/Youtube data
# Herve Jourdain, 2023/07/13

profile default /** flags=(attach_disconnected){
  capability,
  network,
  mount, remount, umount, pivot_root,
  ptrace, signal, dbus, unix,
  /{,**} mrwlk,    # Allows all file access apart from execute permissions
  /{,**} pix,
  change_profile -> **,

  # Deny some sensitive files of /sys
  deny /sys/f[^s]*/** wklx,
  deny /sys/fs/[^c]*/** wklx,
  deny /sys/fs/c[^g]*/** wklx,
  deny /sys/fs/cg[^r]*/** wklx,
  deny /sys/firmware/** wklx,

  # Deny some sensitive files from /proc fs.
  deny /proc/* w,
  deny /proc/{[^1-9],[^1-9][^0-9],[^1-9s][^0-9y][^0-9s],[^1-9][^0-9][^0-9][^0-9/]*}/** w,
  deny /proc/sys/kernel/{?,??,[^s][^h][^m]**} w,
  deny /proc/sysrq-trigger rwklx,
  deny /proc/kcore rwklx,

  # deny access to the data files for AmazonPrime/Youtube
  deny /opt/amazonPrime/{,**} rw,
  deny /opt/persistent/rdkservices/Cobalt-0/{,**} rw,
}

Access to Amazon Prime Video and YouTube data has been denied in the default profile. You can verify this is working by logging in as root via SSH or console and running:

ls -al /opt/amazonPrime

You will get a Permission denied error — even as root. This confirms AppArmor’s MAC policy is successfully overriding the DAC root bypass.

The WPEFramework Profile

The usr.bin.WPEFramework profile is at the heart of all applications in RDK — Premium and non-Premium alike. Since WPEFramework is a single binary launching all apps, there is only one profile, yet we need per-app data isolation.

# Manual profile for the AcceleratorUi/AmazonPrime/Youtube/Metrological apps
# Herve Jourdain, 2023/07/13
profile usr.bin.WPEFramework /usr/bin/WPEFramework {
  #include "/etc/apparmor.d/inc/soc"
  #include "/etc/apparmor.d/inc/oem"

  signal, ptrace,
  capability kill net_admin dac_override dac_read_search
              setgid setuid sys_admin sys_nice,

  /version.txt r,
  /application/{,**} rmix,
  /{,usr/}bin/{,**} rmix,
  /certificate/{,**} rw,
  /config/{,**} rw,
  /dev/urandom r,
  /dev/tty rw,
  /dev/input/{,**} r,
  /dev/null r,
  /dev/ r,
  /etc/{,**} rm,
  /lib/{,**} rm,
  /proc/cmdline r,
  /proc/cpuinfo r,
  /proc/meminfo r,
  /proc/stat r,
  /proc/sys/kernel/ngroups_max r,
  /proc/sys/kernel/osrelease r,
  /proc/sys/vm/overcommit_memory r,
  /proc/*/auxv r,
  /proc/*/cmdline r,
  /proc/*/fd/ r,
  /proc/*/mounts r,
  /proc/*/maps r,
  /proc/*/net/{,*} r,
  /proc/*/stat r,
  /proc/*/statm r,
  /proc/*/status r,
  /proc/*/task/ r,
  /proc/*/task/*/comm rw,
  /proc/ r,
  /run/{,**} rwmixlk,
  /sys/class/{,**} r,
  /sys/bus/{,**} r,
  /sys/devices/{,**} r,
  /tmp/{,**} rw,
  ...
}

Now that we have established that no process has access to Premium App data by default (via the default profile’s deny rules), we need to enable each Premium App to access its own data — but not the data of any other Premium App.

The solution lies in the use of the owner keyword, which allows only the User designated as the owner of the files to access those files!

# Add to the WPEFramework profile —
# Each Premium App can only access files it owns

# AmazonPrime user can read/write AmazonPrime-owned data only
owner /opt/amazonPrime/{,**} rw,

# YouTube/Cobalt user can read/write Cobalt-owned data only
owner /opt/persistent/rdkservices/Cobalt-0/{,**} rw,

Key insight: The combination of (1) deny rules in the default profile blocking all access to Premium App data directories, and (2) owner rules in the WPEFramework profile allowing each app’s user to access only its own data, achieves genuine cross-app data isolation — without requiring containers. Even root cannot bypass this when AppArmor is in enforce mode.

Setup Requirements

For this to work correctly, ensure:

• Each Premium App runs under its own dedicated non-root Linux user (e.g., amazonprime, youtube)
• Data directories are created with the correct ownership: chown amazonprime:amazonprime /opt/amazonPrime
• AppArmor is in enforce mode (not complain) in production
• The default profile deny rules are in place (see the companion article on production hardening)

By combining proper user separation, strict file ownership, the AppArmor owner keyword, and MAC enforce mode, you can achieve robust Premium App data isolation in RDK without the overhead of a full container runtime — a pragmatic and effective choice for constrained STB/TV hardware where RDK6 container support may not yet be available.