From patchwork Fri Mar 2 22:21:12 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Biggers X-Patchwork-Id: 880928 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-ext4-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="Tdzeyk6B"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3ztP2T5p37z9s8r for ; Sat, 3 Mar 2018 09:23:13 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932293AbeCBWXM (ORCPT ); Fri, 2 Mar 2018 17:23:12 -0500 Received: from mail-io0-f195.google.com ([209.85.223.195]:43205 "EHLO mail-io0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932266AbeCBWXK (ORCPT ); Fri, 2 Mar 2018 17:23:10 -0500 Received: by mail-io0-f195.google.com with SMTP id l12so12157074ioc.10; Fri, 02 Mar 2018 14:23:10 -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:in-reply-to:references; bh=3lGSLojvyX7Syw8Akb0VGLSEBY8kEqFcIkx4apbgKh8=; b=Tdzeyk6BJ69zMxAyzLEoPCLiPJd9hdwkzr+As79j+tWU1SQifnI8PZCCcohFnHYwpC shtPKxC3d9EfEgIjYA64hh49zJvA5ahhlMK8VFIKz+vvap7UZLsVq1dD2k0vgNevb0Qy NwcDFqJvYGWnx1Sqy1ZuZLzzs8DP1ITvQXrFdyGeqMWuwfdJ56Zy9eProOASvM88cImi RQTi5J3OEEGEth+lxURZE0wC2acA0a6l+OovhIpGi8ONkrOECEQA0+WLy+gWN+9YL8TU C6e74XIXo1xzpO8Ie8zZ7lMM9CT7KJ1ZJsK1yCyWGy3Ha3edph3QLcMKlMtXMNgl+ob3 ibDg== 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:in-reply-to :references; bh=3lGSLojvyX7Syw8Akb0VGLSEBY8kEqFcIkx4apbgKh8=; b=B0O4hbKBt+F/OGFUU8BlTDa7Ei7jWpg6RGr5ynLMfg/GZ2pDpQulBjPkgbC4cwIzrC lUDpxDbuXYhv5tR2rvYGl8lXSpC2N4ee5yrOcz3+LBW4lC1ZDKU1tVqmGXPYVmKJH2Dr +m6bTxAIBXtdoceuygmiuOmBdVB41rDfPykKDojtJsRpCB4CCgJrTmc3oI/7SoPm/YpO i59friH64yxYRF1eRRw5OzE/xqNVxA+GyO9IbwroLuMPOiuPq5zowVMUVUIaXFzNrn14 ce7JrlBfkiSIGHOroaO1nTgINSoPkFQtHdWIDWvnLcOuhg/gGgFImc30FnhjHAB1uaet pSGw== X-Gm-Message-State: AElRT7HQpTGV9DmdijGDk7GF/svWMXtORcAFZm2Onh+3QRzq/egoizxy rCPNmPhrJ8rRlym+n4Ew4DCirwjR X-Google-Smtp-Source: AG47ELuyG/bSLNHRI11PNLfFWswya1oQPdSYJP5c3ilty1VDWrGsGgbW0pUGbgG9W/uvqyLdugDGZg== X-Received: by 10.107.160.74 with SMTP id j71mr8332289ioe.10.1520029389530; Fri, 02 Mar 2018 14:23:09 -0800 (PST) Received: from ebiggers-linuxstation.kir.corp.google.com ([2620:15c:17:3:dc28:5c82:b905:e8a8]) by smtp.gmail.com with ESMTPSA id o7sm2496980iod.52.2018.03.02.14.23.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Mar 2018 14:23:09 -0800 (PST) From: Eric Biggers To: stable@vger.kernel.org, Sasha Levin Cc: linux-ext4@vger.kernel.org, Eric Biggers , Theodore Ts'o Subject: [PATCH 4.1 2/3] fscrypto: add authorization check for setting encryption policy Date: Fri, 2 Mar 2018 14:21:12 -0800 Message-Id: <20180302222113.85389-3-ebiggers3@gmail.com> X-Mailer: git-send-email 2.16.2.395.g2e18187dfd-goog In-Reply-To: <20180302222113.85389-1-ebiggers3@gmail.com> References: <20180302222113.85389-1-ebiggers3@gmail.com> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org From: Eric Biggers commit 163ae1c6ad6299b19e22b4a35d5ab24a89791a98 upstream. On an ext4 or f2fs filesystem with file encryption supported, a user could set an encryption policy on any empty directory(*) to which they had readonly access. This is obviously problematic, since such a directory might be owned by another user and the new encryption policy would prevent that other user from creating files in their own directory (for example). Fix this by requiring inode_owner_or_capable() permission to set an encryption policy. This means that either the caller must own the file, or the caller must have the capability CAP_FOWNER. (*) Or also on any regular file, for f2fs v4.6 and later and ext4 v4.8-rc1 and later; a separate bug fix is coming for that. Signed-off-by: Eric Biggers Signed-off-by: Theodore Ts'o --- fs/ext4/crypto_policy.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/ext4/crypto_policy.c b/fs/ext4/crypto_policy.c index a6d6291aea16..591fc37dcd9e 100644 --- a/fs/ext4/crypto_policy.c +++ b/fs/ext4/crypto_policy.c @@ -85,6 +85,9 @@ static int ext4_create_encryption_context_from_policy( int ext4_process_policy(const struct ext4_encryption_policy *policy, struct inode *inode) { + if (!inode_owner_or_capable(inode)) + return -EACCES; + if (policy->version != 0) return -EINVAL;