btrfs snapshots, rollbacks

[Chris Murphy]

On Feb 17, 2014, at 3:40 PM, Till Maas <opensource at till.name> wrote:

> On Wed, Feb 12, 2014 at 07:16:34PM -0700, Chris Murphy wrote:
> 
>> 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.
> 
> If old snapshots are mounted, there are several possible security
> implications:

Just to be clear, the old snapshot doesn't necessarily need to be mounted for it to be available. If the snapshot is located below a mounted subvolume, then it's available as if it were a normal directory. That's the case here, where yum-plugin-fs-snapshot takes a snapshot of /, and places it in the root of the mounted file system (which on Fedora is a mounted Btrfs subvolume named "root").

If instead they were placed either at the top level of the Btrfs file system (in subvolume id 5, along with the root and home subvolumes) they'd effectively be hidden since the top level isn't normally mounted. 

So a more thorough look at this would be whether a DE can be tricked into mounting that top level. And whether a compromised root user can mount subvolumes/snapshots over existing rootfs directories such as /lib.



> 
> An old snapshot might contain
> 
> - A world-readable confidential files thats permissions were fixed after
>  creating the snapshot, e.g. /etc/pki/tls/private/foo.key
> 
> - A confidential file with too many ACLs that were fixed after creating
>  the snapshot
> 
> - A confidential file with the bad selinux context allowing to be read
>  by an exploited daemon
> 
> - A vulnerable suid binary
> 
> - A vulnerable binary with capabilities
> 
> - An executable with the wrong selinux context allowing an exploited
>  daemon to execute a binary that is not executable on the current
>  system
> 
> - A device file with bad permissions/ACL/selinux context
> 
> Therefore I guess it needs to be made sure that no unprivileged process
> can access the contents of a mounted snapshot.


RFE: btrfs rootfs snapshots should be placed outside the mounted path
https://bugzilla.redhat.com/show_bug.cgi?id=1060241

Depending on the concern and how strict the security policy needs to be:

a. Only place such snapshots outside of the the mounted file system; i.e. don't create the snapshot of a subvolume inside that same subvolume. For example, not this:
btrfs subvolume snapshot /var.1 /var
But rather:
mount -o subvol=snapshots <device> /mnt/snapshots
btrfs subvolume snapshot /mnt/snapshots/var.1 /var
umount /mnt/snapshots

b. Per above, but then use btrfs send to put the data onto a completely separate file system, possibly with -f switch so that it's a file, and then we can set some stringent selinux label to how it's accessed.

c. Don't use snapshots. Maybe we need an selinux policy that inhibits the creation of snapshots for certain subvolumes? Even by root?



> Maybe the root directory
> can be protected with strict permissions/ACLs and a selinux context that
> does not allow anything else to access the contents.

Some way to make rootfs snapshot contents non-executable unless they're mounted by root? Or unless they're mounted at boot time (i.e. a rollback). It sounds like a layered, or conditional context, that would apply if a containing "snapshots" subvolume is mounted; but if an actual rootfs snapshot itself where mounted, such as at boot time, its usual selinux labeling applies. Is this possible?


Chris Murphy