Re: Security implications of btrfs receive?

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

On 2016-09-09 12:18, David Sterba wrote:
> On Wed, Sep 07, 2016 at 07:58:30AM -0400, Austin S. Hemmelgarn wrote:
>> 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.
>
> What if the stream is verified first? Ie. look if there are the
> operations using subolumes not owned by the user.
>
I think that extending the ioctl to require proof of access to the 
source being cloned from would be a better approach to this, as this is 
an issue with the ioctl in general, it's just discussion of send/receive 
that brought this up.  I'm actually kind of surprised that this didn't 
get noticed before, seeing as it's a pretty significant and not all that 
difficult to use information leak.  Ideally, this needs to be decided 
before the VFS layer clone ioctl gets finalized.