Better support for btrfs snapshots

Bug #484786 reported by John Dong
360
This bug affects 4 people
Affects Status Importance Assigned to Milestone
AppArmor
Triaged
Medium
Unassigned
apparmor (Ubuntu)
Triaged
Medium
Unassigned
linux (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

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.

WeatherGod (ben-v-root)
security vulnerability: no → yes
Revision history for this message
Micah Gersten (micahg) wrote :

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

visibility: public → private
Revision history for this message
John Dong (jdong) wrote :

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)
Changed in apparmor (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Kees Cook (kees) wrote :

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

visibility: private → public
tags: added: aa-feature
summary: - Too easy to circumvent AppArmor using btrfs snapshots
+ Better support btrfs snapshots
Changed in apparmor (Ubuntu):
importance: Medium → Low
Changed in apparmor:
importance: Undecided → Medium
status: New → Triaged
summary: - Better support btrfs snapshots
+ Better support for btrfs snapshots
tags: added: aa-kernel
Changed in apparmor (Ubuntu):
importance: Low → Medium
status: Confirmed → Triaged
Changed in linux (Ubuntu):
status: New → Triaged
Changed in linux (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Simon Déziel (sdeziel) wrote :

Nowadays, btrfs snapshots can only be taken by the owner of the source subvol. https://btrfs.readthedocs.io/en/latest/ch-mount-options.html#btrfs-specific-mount-options:

> Historically, any user could create a snapshot even if he was not owner of the source subvolume, the subvolume deletion has been restricted for that reason. The subvolume creation has been restricted ...

I just tested this in a Jammy VM (FYI btrfsctl was replaced by `btrfs subvolume snapshot`):

```
ubuntu@bj:~$ uname -a
Linux bj 5.15.0-75-generic #82-Ubuntu SMP Tue Jun 6 23:10:23 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@bj:~$ dpkg -l| grep btrfs
ii btrfs-progs 5.16.2-1 amd64 Checksumming Copy on Write Filesystem utilities

ubuntu@bj:~$ mount | grep btrfs
/dev/sda3 on /home type btrfs (rw,noatime,space_cache=v2,subvolid=5,subvol=/)

# Trying while /home is root owned
ubuntu@bj:~$ btrfs subvolume snapshot /home ./homefoo
Create a snapshot of '/home' in './homefoo'
ERROR: cannot snapshot '/home': Operation not permitted

# Changing ownership of the source subvol
ubuntu@bj:~$ sudo chown ubuntu: /home

# Trying now that /home is owned by ubuntu:
ubuntu@bj:~$ btrfs subvolume snapshot /home ./homefoo
Create a snapshot of '/home' in './homefoo'
```

So I don't think it's a concern anymore but I won't fiddle with the bug status and leave that to others ;)

To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.