On Jan 24, 2014, at 9:40 PM, Josh Stone <jistone@xxxxxxxxxx> wrote: > On 01/24/2014 05:27 PM, Chris Murphy wrote: >> On Jan 24, 2014, at 4:16 PM, Josh Stone <jistone@xxxxxxxxxx> wrote: >>> This concerns me especially in the case of security updates -- for >>> example, a vulnerable setuid-root binary should be locked up tight! >> >> The organization question is valid. But sudo or root could just mount >> any subvolume. However, btrfs read-only snapshots can't be written to >> even by root. Naturally root could just create a rw snapshot of a ro >> snapshot and then delete the ro snapshot, but an audit probably ought >> to show the subvolume UUIDs and creation dates involved so that we'd >> know this is what happened. > > My point was not about what root can do. Suppose there's a vulnerable > 'sudo' binary that gives everyone a root shell. If that binary is > available on any executable path, even readonly, that's trouble. OK, so is the fact it's persistently available the problem? Because if I were to have a persistent backup of sysroot mounted, I've got the same attack vector available. By default for even an unprivileged user gnome-shell mounts with By default, gnome-shell mounts volumes with rw,nosuid,nodev,relatime,seclabel,uhelper=udisks2. > > As you say, LVM snapshots are out of view, but with btrfs it needs to be > an inaccessible subvolume path, or mounted noexec, etc. To make inaccessible: mount a subvol outside of the presently mounted path, snapshot, umount. Seems like I can independently mount subvolumes with noexec: 49 37 0:45 /isos /mnt/isos rw,relatime shared:35 - btrfs /dev/sdb rw,seclabel,compress=lzo,space_cache 177 37 0:45 /archive /mnt/root rw,noexec,relatime shared:159 - btrfs /dev/sdb rw,seclabel,compress=lzo,space_cache So another possibility is to have a "snapshots" subvolume persistently mounted, with noexec, and always place snapshots in that subvolume. Chris Murphy -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
