From patchwork Fri Feb 3 13:48:58 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Austin S. Hemmelgarn" X-Patchwork-Id: 9554125 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 99FCD604A7 for ; Fri, 3 Feb 2017 13:49:26 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 879D02818E for ; Fri, 3 Feb 2017 13:49:26 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 79117284DB; Fri, 3 Feb 2017 13:49:26 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0C08F2818E for ; Fri, 3 Feb 2017 13:49:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752645AbdBCNtX (ORCPT ); Fri, 3 Feb 2017 08:49:23 -0500 Received: from mail-io0-f196.google.com ([209.85.223.196]:34804 "EHLO mail-io0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752248AbdBCNtW (ORCPT ); Fri, 3 Feb 2017 08:49:22 -0500 Received: by mail-io0-f196.google.com with SMTP id c80so2245236iod.1 for ; Fri, 03 Feb 2017 05:49:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=icNlihcFEvRD7cM/QsNnuiVFdZDMErl2JxQzPt4OGu0=; b=FzGOw/InE7IXdGwpiqQep4yvSnsh6e3yQh7W5hrjPB9fkompnIK/3Cfzaz3PP3W4Id 4Hh3aGp6/7W3jmCttRokZN24BcknFiUZdh7QUErOrVbPrfbPc7fuuqNlt7T9Z9U/hIZU JccRWhlNUA5tXkoo1dFGx8ZWIxr03kHGf5dgGvjMRFMFj7tLrj8FI+dvwQw9ajRkmoWu G10IZYny0Xp8nwPph0MFJpvQqQgjVO/9JPtlo0OjwFQhU9hRwwS0DHLnQsVJnMUV6z3Z Hj3aNcZe26SB//uf34fyyZHhD0UTUELK2lPSwA+rT4cBWGGRvHjduVRbLInqgkdy6QW4 cG2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=icNlihcFEvRD7cM/QsNnuiVFdZDMErl2JxQzPt4OGu0=; b=an60JhqYzLycc05JCvbM2e0t3GJMz7vLo7S2r8q6uhzQTNRRKds3GECJvMuwoBouFj z0kgUnxKF+kB4Bk3pGREepFpxSS0Mt8AO7qJpaHD2DvOfIM3sHCcy6eXvU8JzUQiSZby 3SDlx5pNulEM0fmntpgZ919071vIKXomv0dgB2aVMjgYPMj9s29HjylGQQp75GhYisdg Lu45+oMUb0rgj/2GVkVnLLjfEI96zaqUVuKDroFgdAwb/IRBjstB0KozQ++b2lAi3rwM J/ZW7UAHGmxoZ76bLHF4LszEwEFCBdDIqTmWq0ZlVAZrm30pgOnXGMCsTpAryIX+FT8x yNrw== X-Gm-Message-State: AIkVDXJ+kmI/xV7lUADe+6hB6c/coL8VwLCliOG8UW3AG+bSRPsM8hkgpat3yX/43FlOfQ== X-Received: by 10.107.35.142 with SMTP id j136mr10566679ioj.158.1486129762136; Fri, 03 Feb 2017 05:49:22 -0800 (PST) Received: from wild-karde.localdomain (rrcs-70-62-41-24.central.biz.rr.com. [70.62.41.24]) by smtp.googlemail.com with ESMTPSA id v197sm2969524ita.2.2017.02.03.05.49.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Feb 2017 05:49:21 -0800 (PST) Received: by wild-karde.localdomain (Postfix, from userid 1000) id 3D38A1EBFDC5; Fri, 3 Feb 2017 08:49:16 -0500 (EST) From: "Austin S. Hemmelgarn" To: linux-btrfs@vger.kernel.org, dsterba@suse.cz Cc: "Austin S. Hemmelgarn" Subject: [PATCH] btrfs-progs: better document btrfs receive security Date: Fri, 3 Feb 2017 08:48:58 -0500 Message-Id: <20170203134858.75210-1-ahferroin7@gmail.com> X-Mailer: git-send-email 2.11.0 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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 --- 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