From: Eric Biggers <ebiggers3@gmail.com>
To: linux-fsdevel@vger.kernel.org
Cc: tytso@mit.edu, Eric Biggers <ebiggers3@gmail.com>,
mhalcrow@google.com, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net, jaegeuk@kernel.org,
linux-ext4@vger.kernel.org
Subject: [PATCH 11/13] fscrypto: restrict setting encryption policy to inode owner
Date: Sun, 3 Apr 2016 00:22:02 -0500 [thread overview]
Message-ID: <1459660924-2960-12-git-send-email-ebiggers3@gmail.com> (raw)
In-Reply-To: <1459660924-2960-1-git-send-email-ebiggers3@gmail.com>
On a filesystem with encryption enabled, a user could set an encryption
policy on any empty directory to which they have readonly access. This
is a potential security issue since such a directory might be owned by
another user, and the new encryption policy may prevent that user from
creating files in their own directory.
Fix this by requiring inode_owner_or_capable() permission to set an
encryption policy.
Signed-off-by: Eric Biggers <ebiggers3@gmail.com>
---
fs/crypto/policy.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/crypto/policy.c b/fs/crypto/policy.c
index cb5ba27..3f5c275 100644
--- a/fs/crypto/policy.c
+++ b/fs/crypto/policy.c
@@ -96,6 +96,9 @@ int fscrypt_set_policy(struct inode *inode, const struct fscrypt_policy *policy)
{
int ret = 0;
+ if (!inode_owner_or_capable(inode))
+ return -EACCES;
+
if (policy->version != 0)
return -EINVAL;
--
2.7.4
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers3@gmail.com>
To: linux-fsdevel@vger.kernel.org
Cc: linux-f2fs-devel@lists.sourceforge.net,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
jaegeuk@kernel.org, tytso@mit.edu, mhalcrow@google.com,
Eric Biggers <ebiggers3@gmail.com>
Subject: [PATCH 11/13] fscrypto: restrict setting encryption policy to inode owner
Date: Sun, 3 Apr 2016 00:22:02 -0500 [thread overview]
Message-ID: <1459660924-2960-12-git-send-email-ebiggers3@gmail.com> (raw)
In-Reply-To: <1459660924-2960-1-git-send-email-ebiggers3@gmail.com>
On a filesystem with encryption enabled, a user could set an encryption
policy on any empty directory to which they have readonly access. This
is a potential security issue since such a directory might be owned by
another user, and the new encryption policy may prevent that user from
creating files in their own directory.
Fix this by requiring inode_owner_or_capable() permission to set an
encryption policy.
Signed-off-by: Eric Biggers <ebiggers3@gmail.com>
---
fs/crypto/policy.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/crypto/policy.c b/fs/crypto/policy.c
index cb5ba27..3f5c275 100644
--- a/fs/crypto/policy.c
+++ b/fs/crypto/policy.c
@@ -96,6 +96,9 @@ int fscrypt_set_policy(struct inode *inode, const struct fscrypt_policy *policy)
{
int ret = 0;
+ if (!inode_owner_or_capable(inode))
+ return -EACCES;
+
if (policy->version != 0)
return -EINVAL;
--
2.7.4
next prev parent reply other threads:[~2016-04-03 5:22 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-03 5:21 [PATCH 00/13] fscrypto: cleanups and fixes Eric Biggers
2016-04-03 5:21 ` Eric Biggers
2016-04-03 5:21 ` [PATCH 01/13] fscrypto: remove unnecessary includes Eric Biggers
2016-04-03 5:21 ` Eric Biggers
2016-04-03 5:21 ` [PATCH 02/13] fscrypto: rename some functions for clarity Eric Biggers
2016-04-03 5:21 ` Eric Biggers
2016-04-03 7:45 ` Theodore Ts'o
2016-04-03 7:45 ` Theodore Ts'o
2016-04-03 5:21 ` [PATCH 03/13] fscrypto: rename functions to load and unload inode encryption info Eric Biggers
2016-04-03 5:21 ` Eric Biggers
2016-04-03 5:21 ` [PATCH 04/13] fscrypto: return bool instead of int where appropriate Eric Biggers
2016-04-03 5:21 ` Eric Biggers
2016-04-03 5:21 ` [PATCH 05/13] fscrypto: comment improvements and fixes Eric Biggers
2016-04-03 5:21 ` Eric Biggers
2016-04-03 5:21 ` [PATCH 06/13] fscrypto: crypto_alloc_skcipher() always returns an ERR_PTR(), never NULL Eric Biggers
2016-04-03 5:21 ` Eric Biggers
2016-04-03 5:21 ` [PATCH 07/13] fscrypto: simplify building key descriptor string Eric Biggers
2016-04-03 5:21 ` Eric Biggers
2016-04-03 5:21 ` [PATCH 08/13] fscrypto: use standard macros from kernel.h Eric Biggers
2016-04-03 5:21 ` Eric Biggers
2016-04-03 5:22 ` [PATCH 09/13] fscrypto: make fname_encrypt() actually return length of ciphertext Eric Biggers
2016-04-03 5:22 ` Eric Biggers
2016-04-03 5:22 ` [PATCH 10/13] fscrypto: restrict setting new policy to empty files and directories only Eric Biggers
2016-04-03 5:22 ` Eric Biggers
2016-04-03 5:22 ` Eric Biggers [this message]
2016-04-03 5:22 ` [PATCH 11/13] fscrypto: restrict setting encryption policy to inode owner Eric Biggers
2016-04-03 5:22 ` [PATCH 12/13] fscrypto: require write access to mount to set encryption policy Eric Biggers
2016-04-03 5:22 ` Eric Biggers
2016-04-03 5:22 ` [PATCH 13/13] fscrypto: improve error handling in fscrypt_set_policy() Eric Biggers
2016-04-03 5:22 ` Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1459660924-2960-12-git-send-email-ebiggers3@gmail.com \
--to=ebiggers3@gmail.com \
--cc=jaegeuk@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhalcrow@google.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.