* [PATCH] btrfs-progs: better document btrfs receive security
@ 2017-02-03 13:48 Austin S. Hemmelgarn
2017-02-07 18:27 ` David Sterba
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Austin S. Hemmelgarn @ 2017-02-03 13:48 UTC (permalink / raw)
To: linux-btrfs, dsterba; +Cc: Austin S. Hemmelgarn
This adds some extra documentation to the btrfs-receive manpage that
explains some of the security related aspects of btrfs-receive. The
first part covers the fact that the subvolume being received is writable
until the receive finishes, and the second covers the current lack of
sanity checking of the send stream.
Signed-off-by: Austin S. Hemmelgarn <ahferroin7@gmail.com>
---
Inspired by a recent thread on the ML.
This could probably be more thorough, but I felt it was more important
to get it documented as quickly as possible, and this should cover the
basic info that most people will care about.
Documentation/btrfs-receive.asciidoc | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/Documentation/btrfs-receive.asciidoc b/Documentation/btrfs-receive.asciidoc
index a6838e5e..1ada396f 100644
--- a/Documentation/btrfs-receive.asciidoc
+++ b/Documentation/btrfs-receive.asciidoc
@@ -68,6 +68,26 @@ dump the stream metadata, one line per operation
+
Does not require the 'path' parameter. The filesystem chanded.
+SECURITY
+--------
+Because of how *btrfs receive* works, subvolumes that are in the
+process of being received are writable. As a result of this, there
+is a possibility that a subvolume for which the receive operation just
+completed may not be identical to the originally sent subvolume.
+
+To avoid this in cases where more than one user may have access to the
+area the received subvolumes are being stored, it is reccommended to
+receive subvolumes into a staging area which is only accessible to the
+user who is running receive, and then move then into the final destination
+when the receive command completes.
+
+Additionally, receive does not currently do a very good job of validating
+that an incremental send streams actually makes sense, and it is thus
+possible for a specially crafted send stream to create a subvolume with
+reflinks to arbitrary files in the same filesystem. Because of this,
+users are advised to not use *btrfs receive* on send streams from
+untrusted sources.
+
EXIT STATUS
-----------
*btrfs receive* returns a zero exit status if it succeeds. Non zero is
--
2.11.0
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH] btrfs-progs: better document btrfs receive security
2017-02-03 13:48 [PATCH] btrfs-progs: better document btrfs receive security Austin S. Hemmelgarn
@ 2017-02-07 18:27 ` David Sterba
2017-02-08 12:29 ` Austin S. Hemmelgarn
2017-02-07 22:32 ` Kai Krakow
2017-02-07 22:40 ` Kai Krakow
2 siblings, 1 reply; 6+ messages in thread
From: David Sterba @ 2017-02-07 18:27 UTC (permalink / raw)
To: Austin S. Hemmelgarn; +Cc: linux-btrfs
On Fri, Feb 03, 2017 at 08:48:58AM -0500, Austin S. Hemmelgarn wrote:
> This adds some extra documentation to the btrfs-receive manpage that
> explains some of the security related aspects of btrfs-receive. The
> first part covers the fact that the subvolume being received is writable
> until the receive finishes, and the second covers the current lack of
> sanity checking of the send stream.
>
> Signed-off-by: Austin S. Hemmelgarn <ahferroin7@gmail.com>
Applied, thanks.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] btrfs-progs: better document btrfs receive security
2017-02-07 18:27 ` David Sterba
@ 2017-02-08 12:29 ` Austin S. Hemmelgarn
2017-02-08 12:55 ` David Sterba
0 siblings, 1 reply; 6+ messages in thread
From: Austin S. Hemmelgarn @ 2017-02-08 12:29 UTC (permalink / raw)
To: dsterba, linux-btrfs
On 2017-02-07 13:27, David Sterba wrote:
> On Fri, Feb 03, 2017 at 08:48:58AM -0500, Austin S. Hemmelgarn wrote:
>> This adds some extra documentation to the btrfs-receive manpage that
>> explains some of the security related aspects of btrfs-receive. The
>> first part covers the fact that the subvolume being received is writable
>> until the receive finishes, and the second covers the current lack of
>> sanity checking of the send stream.
>>
>> Signed-off-by: Austin S. Hemmelgarn <ahferroin7@gmail.com>
>
> Applied, thanks.
>
Didn't get a chance to mention this yesterday, but it looks like you
hadn't seen the updated version I sent on the third. Message ID is:
<20170203193805.96977-1-ahferroin7@gmail.com>
The only significant difference is that I updated the description for
the writablility issue using a much better description from Graham Cobb
(with his permission of course).
If you want, I can send an incremental patch on top of the original to
update just that description.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] btrfs-progs: better document btrfs receive security
2017-02-08 12:29 ` Austin S. Hemmelgarn
@ 2017-02-08 12:55 ` David Sterba
0 siblings, 0 replies; 6+ messages in thread
From: David Sterba @ 2017-02-08 12:55 UTC (permalink / raw)
To: Austin S. Hemmelgarn; +Cc: linux-btrfs
On Wed, Feb 08, 2017 at 07:29:22AM -0500, Austin S. Hemmelgarn wrote:
> On 2017-02-07 13:27, David Sterba wrote:
> > On Fri, Feb 03, 2017 at 08:48:58AM -0500, Austin S. Hemmelgarn wrote:
> >> This adds some extra documentation to the btrfs-receive manpage that
> >> explains some of the security related aspects of btrfs-receive. The
> >> first part covers the fact that the subvolume being received is writable
> >> until the receive finishes, and the second covers the current lack of
> >> sanity checking of the send stream.
> >>
> >> Signed-off-by: Austin S. Hemmelgarn <ahferroin7@gmail.com>
> >
> > Applied, thanks.
> >
> Didn't get a chance to mention this yesterday, but it looks like you
> hadn't seen the updated version I sent on the third. Message ID is:
> <20170203193805.96977-1-ahferroin7@gmail.com>
Ah sorry I missed that.
> The only significant difference is that I updated the description for
> the writablility issue using a much better description from Graham Cobb
> (with his permission of course).
>
> If you want, I can send an incremental patch on top of the original to
> update just that description.
No need to, I'll replace the patch with the latest version. Thanks.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] btrfs-progs: better document btrfs receive security
2017-02-03 13:48 [PATCH] btrfs-progs: better document btrfs receive security Austin S. Hemmelgarn
2017-02-07 18:27 ` David Sterba
@ 2017-02-07 22:32 ` Kai Krakow
2017-02-07 22:40 ` Kai Krakow
2 siblings, 0 replies; 6+ messages in thread
From: Kai Krakow @ 2017-02-07 22:32 UTC (permalink / raw)
To: linux-btrfs
Am Fri, 3 Feb 2017 08:48:58 -0500
schrieb "Austin S. Hemmelgarn" <ahferroin7@gmail.com>:
> +user who is running receive, and then move then into the final
> destination ^^^^
Typo? s/then/them/?
--
Regards,
Kai
Replies to list-only preferred.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] btrfs-progs: better document btrfs receive security
2017-02-03 13:48 [PATCH] btrfs-progs: better document btrfs receive security Austin S. Hemmelgarn
2017-02-07 18:27 ` David Sterba
2017-02-07 22:32 ` Kai Krakow
@ 2017-02-07 22:40 ` Kai Krakow
2 siblings, 0 replies; 6+ messages in thread
From: Kai Krakow @ 2017-02-07 22:40 UTC (permalink / raw)
To: linux-btrfs
Am Fri, 3 Feb 2017 08:48:58 -0500
schrieb "Austin S. Hemmelgarn" <ahferroin7@gmail.com>:
> +that an incremental send streams actually makes sense, and it is thus
> +possible for a specially crafted send stream to create a subvolume
Sorry for the noise... Another one: shouldn't it say "sent
stream" (minus s) and "sent"?
--
Regards,
Kai
Replies to list-only preferred.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-02-08 13:14 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-02-03 13:48 [PATCH] btrfs-progs: better document btrfs receive security Austin S. Hemmelgarn
2017-02-07 18:27 ` David Sterba
2017-02-08 12:29 ` Austin S. Hemmelgarn
2017-02-08 12:55 ` David Sterba
2017-02-07 22:32 ` Kai Krakow
2017-02-07 22:40 ` Kai Krakow
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).