Drawing lessons from fatal SELinux bug #1054350

[Chris Murphy]

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

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