Better support for btrfs snapshots

[John Dong]

Binary package hint: apparmor

I just realized that the btrfs snapshotting ioctl is usable by all users, not root as I previously assumed. This makes it concerningly easy for users on btrfs to defeat a path-based MAC framework like AppArmor.

For example, consider the gdm-guest-session user. If I log into a gdm-guest-session on btrfs:

(1) ls /home ==> Permission denied as expected, by AppArmor.

(2) cd /tmp

(3) btrfsctl -s test / (Make a snapshot of / in /tmp called test)

(4) cd /tmp/test

(5) Profit! Apparmor-unrestricted mirror of / in /tmp/test!

As btrfs inevitably will become a mainstream filesystem, it's a good time to begin thinking about how to handle this situation.

[Micah Gersten (micahg)]

Marked as private for the moment until this is looked at by the security team.

[John Dong (jdong)]

Upon a bit of further investigation, it's interesting to note that btrfs snapshots preserve ownership (i.e. btrfsctl -S test / --> test is owned by root:root just like /)

So, one workaround is the policy invariant "Any directories where a confined process can write to should only be granted owner read permissions", though this is a pretty subpar workaround...

Even in a fairly restricted apparmor profile, as long as inherit-execute permissions are available to the btrfsctl binary,and write permissions exist to the snapshot destination, btrfs snapshotting will succeed. No further AA capabilities are required, which is a bit concerning.

[Kees Cook (kees)]

Sounds like the ioctl to create snapshots should be confined by the profile.