On Jan 24, 2014, at 9:40 PM, Josh Stone <jistone(a)redhat.com> wrote:
On 01/24/2014 05:27 PM, Chris Murphy wrote:
> On Jan 24, 2014, at 4:16 PM, Josh Stone <jistone(a)redhat.com> 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