Shortish version: On Fedora devel@, a concern has been raised regarding binaries with vulnerablities being persistently available via Btrfs snapshots in the normal file system hierarchy. This is a request for assessing the significance of this concern, and how to mitigate it. Therefore the context is rootfs on Btrfs. The first email bringing up the concern is here: https://lists.fedoraproject.org/pipermail/devel/2014-January/194558.html And a possible work around proposed here: https://lists.fedoraproject.org/pipermail/devel/2014-January/194620.html How significant is the risk of stale binaries being persistently available in the normal file system hierarchy? Should something be done to either make sure they aren't persistently available (make sure they aren't available in the mounted file system hierarchy), and if they're mounted should noexec or nosuid be used? Slightly longer version: Other distros install to Btrfs the way they do any other file system. This means any snapshots are available via the mounted top level of the file system. Fedora on the other hand has a different layout, with a subvolume named root in the top level of the file system. Inside this subvolume is the tree you'd normally find as rootfs. Instead of the top level file system being mounted, the root subvolume is mounted at /. This means it's possible to "hide" snapshots in the unmounted top level of the file system; or nested within a subvolume called snapshots, for example. Presently, the optional yum-plugin-fs-snapshot creates snapshots of subvolumes prior to updates, and places the snapshots in the parent subvolume. (Since snapshotting subvolumes isn't recursive, the snapshots themselves aren't snapshot.) For example: #btrfs subvolume list / ID 256 gen 352 top level 5 path root ID 257 gen 352 top level 5 path home ID 266 gen 95 top level 256 path yum_20140212183241 ID 267 gen 97 top level 5 path home/yum_20140212183242 Because the snapshot is located within a mounted subvolume, it makes the snapshot's stale binaries persistently available. So restating the earlier question, is this a security risk, how significant is it, and is it worth changing the behavior? Instead, these yum snapshots could be placed in a subvolume at the top level of the file system, which isn't mounted by default. The other question is whether there's a meaningful distinction between persistently mounting this snapshots subvolume, or only mounting it on demand when snapshots are about to be taken? And then when it's mounted, should the mount option be noexec or nosuid. For what it's worth, the questions use this yum plug in as an example, but I'm uncertain if a future snapshot/rollback strategy will actually use it, or snapper, or some other utility entirely. Rollbacks and logs: Another thing that comes to mind, is the possibility of doing a rollback on the system. The yum snapshot plugin doesn't automatically do, or aid the user in doing rollbacks. Optional package snapper can. Setting aside, for the moment, the granularity needed to properly do such rollbacks with file system snapshots, I'm wondering about logging behavior from a security perspective. It seems pretty clear to me we'd want a single persistent audit log kept, regardless of which snapshot is booted. Some of the questions I have are, what logs shouldn't be rolled back? Maybe none should be? And is there a use case for snapshotting, for example /var/log, but simply not rolling it back. For what it's worth, Btrfs supports read only snapshots. They're not writable even by root, and even if they're mounted with a rw option. The snapshot also contains a UUID, as well as its parent's UUID. So, I don't know, maybe there's some benefit to the audit daemon tracking this information in a persistent log that we simply never rollback, even if it's being snapshot. A part of the dialog I hope this generates is not only what we should be doing, but also how important it is to do it, as it might affect how anaconda creates its layouts for different Fedora.next products. Do any of the questions or concerns (and unasked questions of course) have different answers depending on whether the context is workstation, server, or cloud? Thanks, Chris Murphy Chris Murphy