From patchwork Fri Feb 3 19:38:05 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: 9555023 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 D1670604A7 for ; Fri, 3 Feb 2017 19:38:22 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C7AE0269DA for ; Fri, 3 Feb 2017 19:38:22 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B979928178; Fri, 3 Feb 2017 19:38:22 +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 D5A75269DA for ; Fri, 3 Feb 2017 19:38:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752081AbdBCTiS (ORCPT ); Fri, 3 Feb 2017 14:38:18 -0500 Received: from mail-io0-f194.google.com ([209.85.223.194]:33360 "EHLO mail-io0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752026AbdBCTiR (ORCPT ); Fri, 3 Feb 2017 14:38:17 -0500 Received: by mail-io0-f194.google.com with SMTP id 101so3261441iom.0 for ; Fri, 03 Feb 2017 11:38:17 -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=hbQHhThnAgko58Pz3i/fQv3tLhbKi7EubWKG5IoLoA8=; b=kVDQJj2RVbdZpEXr0xKkkXzz+YY1NIyrHQf/lFj2loor0J4PkjqGNVn/16uSpU3mbG AxPHq2i4hVkQkA6ySwjFYiCrk3SxYOlv8eQOLWXgr6xNQHd+9cwXBYJ7QjgT4LUQUmfR idyo2wpMrLW5NOTTzKpGak+OvdzitKDjm93JfL+5vXwgSoJBHkquVcRPaAganyBVXgKm /uNhCtjQg9btrdJJsdgI+GJRT1W35u8AG/BLQoZJ3h8J2bq8mEOfG2lCDIT2u67HYOBF FQh6J8xDTRDSX6lu3s/TZ0mXZgHDiPmIkdvjgUbJHYpFfdiBQPBGywyDITm6cN8eJDYh tmEA== 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=hbQHhThnAgko58Pz3i/fQv3tLhbKi7EubWKG5IoLoA8=; b=QkZNbkwVuf8CPaM/tLauPhUPhwZauW/wwXCeBSu5eoE/qtpRUtHAI7+s2l+W59QC0g M3DsdQ1yLBBxtuJltSQliZ2SxS34ydtAfptZ5Co/ouCSoVccJ2AXks76GwwWL0D0xJzD 8g1siWQETXw1+CcEi/QAH1F6xbIpn9DomaePnPUuNqGgH5ME4igOBqS7X4ThZZtjQqxx RtkkfUrFoUTQhC61GHUw/mN7ptzl9srDAhGedHjScLmGorohQrwyQQR0KZEmx1UbounR I+bTE6WoYo61jbN0mzGhDSFLImfWd6oXAh23bc4F4SF7YqstTU7pGUL32Y8FhcwAbGAe nF5Q== X-Gm-Message-State: AIkVDXI4A6RG3Ly+UcsnJSNueuFaJ/mmhh58IhedR53uQQPII1/kpohN5CDdh6B8AXiqaw== X-Received: by 10.107.16.208 with SMTP id 77mr11969658ioq.25.1486150696812; Fri, 03 Feb 2017 11:38:16 -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 e9sm3101435ioe.33.2017.02.03.11.38.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Feb 2017 11:38:15 -0800 (PST) Received: by wild-karde.localdomain (Postfix, from userid 1000) id B83491EC2DEF; Fri, 3 Feb 2017 14:38:14 -0500 (EST) From: "Austin S. Hemmelgarn" To: linux-btrfs@vger.kernel.org, dsterba@suse.cz Cc: g.btrfs@cobb.uk.net, "Austin S. Hemmelgarn" Subject: [PATCH v2] btrfs-progs: better document btrfs receive security Date: Fri, 3 Feb 2017 14:38:05 -0500 Message-Id: <20170203193805.96977-1-ahferroin7@gmail.com> X-Mailer: git-send-email 2.11.1 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 Suggested-by: Graham Cobb --- Chages since v1: * Updated the description based on suggestions from Graham Cobb. 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 @@ -31,7 +31,7 @@ the stream, and print the stream metadata, one operation per line. 3. default subvolume has changed or you didn't mount the filesystem at the toplevel subvolume -A subvolume is made read-only after the receiving process finishes succesfully. +A subvolume is made read-only after the receiving process finishes succesfully (see BUGS below). `Options` @@ -68,6 +68,26 @@ dump the stream metadata, one line per operation + Does not require the 'path' parameter. The filesystem chanded. +BUGS +---- +*btrfs receive* sets the subvolume read-only after it completes +successfully. However, while the receive is in progress, users who have +write access to files or directories in the receiving 'path' can add, +remove, or modify files, in which case the resulting read-only subvolume +will not be an exact copy of the sent subvolume. + +If the intention is to create an exact copy, the receiving 'path' +should be protected from access by users until the receive operation +has completed and the subvolume is set to read-only. + +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, and to protect trusted streams when sending them +across untrusted networks. + EXIT STATUS ----------- *btrfs receive* returns a zero exit status if it succeeds. Non zero is