On Jan 24, 2014, at 9:40 PM, Josh Stone <jist...@redhat.com> wrote:

> On 01/24/2014 05:27 PM, Chris Murphy wrote:
>> On Jan 24, 2014, at 4:16 PM, Josh Stone <jist...@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

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Reply via email to