On 2016-09-06 13:20, Graham Cobb wrote:
Thanks to Austin and Duncan for their replies.
On 06/09/16 13:15, Austin S. Hemmelgarn wrote:
On 2016-09-05 05:59, Graham Cobb wrote:
Does the "path" argument of btrfs-receive mean that *all* operations are
confined to that path? For example, if a UUID or transid is sent which
refers to an entity outside the path will that other entity be affected
or used?
As far as I know, no, it won't be affected.
Is it possible for a file to be created containing shared
extents from outside the path?
As far as I know, the only way for this to happen is if you're
referencing a parent subvolume for a relative send that is itself
sharing extents outside of the path. From a practical perspective,
unless you're doing deduplication on the receiving end, the this
shouldn't be possible.
Unfortunately that is not the case. I decided to do some tests to see
what happens. It is possible for a receive into one path to reference
and access a subvolume from a different path on the same btrfs disk. I
have created a bash script to demonstrate this at:
https://gist.github.com/GrahamCobb/c7964138057e4e092a75319c9fb240a3
This does require the attacker to know the (source) subvolume UUID they
want to copy. I am not sure how hard UUIDs are to guess.
Oh, I forgot about the fact that it checks the whole filesystem for
referenced source subvolumes.
By the way, this is exactly the same whether or not the --chroot option
is specified on the "btrfs receive" command.
Which makes sense, chroot only affects the VFS layer, not the underlying FS.
The next question this raises for me is whether this means that
processes in a chroot or in a container (or in a mandatory access
controls environment) can access files outside the chroot/container if
they know the UUID of the subvolume? After all, btrfs-receive uses
IOCTLs that any program running as root can use.
Yes, it does mean that, but if you want proper security you should be
using a real container system (or better yet, a virtual machine), not
just a chroot. Chroot by itself is not a security mechanism, it's a
safety belt and testing tool. If you actually want to secure something,
chroot should only be part of it, together with isolating it to it's own
filesystem, and using cgroups and namespaces.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
