Drawing lessons from fatal SELinux bug #1054350
lists at colorremedies.com
Sat Jan 25 01:27:13 UTC 2014
On Jan 24, 2014, at 4:16 PM, Josh Stone <jistone at redhat.com> wrote:
> On 01/24/2014 01:38 PM, Chris Murphy wrote:
>> On Jan 24, 2014, at 2:58 AM, Sergio Pascual <sergio.pasra at gmail.com
>>> There is a plugin yum-plugin-fs-snapshot, but it requires better
>>> documentation and system integration.
>> Well I'd go a step further and ask some more basic questions how how
>> many snapshots should be bootable, whether systemd-journal should be
>> persistent across snapshots or snapshot specific, what exactly are we
>> snapshotting, can we require /home be separate (presently we don't
>> require it) in order to support such bootable snapshots, on and on.
> I'd also ask where we keep these snapshots, and how do you prevent
> access to them normally. IIRC, yum-plugin-fs-snapshot makes btrfs
> snapshots as a subvolume directly within the filesystem, which means it
> will still be accessible.
It's possible the utility could mount another subvolume not in the present path, including top level ID 5 (the first and default subvolume by mkfs.btrfs), and place snapshots there, and then unmount.
For LVM thinp snapshots, they become completely out of tree LVs. They aren't accessible unless explicitly mounted.
> 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.
More information about the devel