From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-fscrypt@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-mtd@lists.infradead.org, linux-fsdevel@vger.kernel.org,
linux-crypto@vger.kernel.org, keyrings@vger.kernel.org,
linux-api@vger.kernel.org, Satya Tangirala <satyat@google.com>,
Paul Crowley <paulcrowley@google.com>,
Jaegeuk Kim <jaegeuk@kernel.org>
Subject: Re: [PATCH v8 14/20] fscrypt: allow unprivileged users to add/remove keys for v2 policies
Date: Mon, 12 Aug 2019 20:14:07 -0400 [thread overview]
Message-ID: <20190813001406.GI28705@mit.edu> (raw)
In-Reply-To: <20190805162521.90882-15-ebiggers@kernel.org>
On Mon, Aug 05, 2019 at 09:25:15AM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> Allow the FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY
> ioctls to be used by non-root users to add and remove encryption keys
> from the filesystem-level crypto keyrings, subject to limitations.
>
> Motivation: while privileged fscrypt key management is sufficient for
> some users (e.g. Android and Chromium OS, where a privileged process
> manages all keys), the old API by design also allows non-root users to
> set up and use encrypted directories, and we don't want to regress on
> that. Especially, we don't want to force users to continue using the
> old API, running into the visibility mismatch between files and keyrings
> and being unable to "lock" encrypted directories.
>
> Intuitively, the ioctls have to be privileged since they manipulate
> filesystem-level state. However, it's actually safe to make them
> unprivileged if we very carefully enforce some specific limitations.
>
> First, each key must be identified by a cryptographic hash so that a
> user can't add the wrong key for another user's files. For v2
> encryption policies, we use the key_identifier for this. v1 policies
> don't have this, so managing keys for them remains privileged.
>
> Second, each key a user adds is charged to their quota for the keyrings
> service. Thus, a user can't exhaust memory by adding a huge number of
> keys. By default each non-root user is allowed up to 200 keys; this can
> be changed using the existing sysctl 'kernel.keys.maxkeys'.
>
> Third, if multiple users add the same key, we keep track of those users
> of the key (of which there remains a single copy), and won't really
> remove the key, i.e. "lock" the encrypted files, until all those users
> have removed it. This prevents denial of service attacks that would be
> possible under simpler schemes, such allowing the first user who added a
> key to remove it -- since that could be a malicious user who has
> compromised the key. Of course, encryption keys should be kept secret,
> but the idea is that using encryption should never be *less* secure than
> not using encryption, even if your key was compromised.
>
> We tolerate that a user will be unable to really remove a key, i.e.
> unable to "lock" their encrypted files, if another user has added the
> same key. But in a sense, this is actually a good thing because it will
> avoid providing a false notion of security where a key appears to have
> been removed when actually it's still in memory, available to any
> attacker who compromises the operating system kernel.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Looks good. I'd probably would have used either "mk_secret_sem" or
"mk->mk_secret_sem" in the comments, instead of "->mk_securet_sem",
but that's just a personal style preference. Since you consistently
used the latter, I assume that's a deliberate choice, which is fine.
Feel free to add:
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Satya Tangirala <satyat@google.com>,
linux-api@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org, keyrings@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
linux-ext4@vger.kernel.org, Paul Crowley <paulcrowley@google.com>
Subject: Re: [PATCH v8 14/20] fscrypt: allow unprivileged users to add/remove keys for v2 policies
Date: Tue, 13 Aug 2019 00:14:07 +0000 [thread overview]
Message-ID: <20190813001406.GI28705@mit.edu> (raw)
In-Reply-To: <20190805162521.90882-15-ebiggers@kernel.org>
On Mon, Aug 05, 2019 at 09:25:15AM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> Allow the FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY
> ioctls to be used by non-root users to add and remove encryption keys
> from the filesystem-level crypto keyrings, subject to limitations.
>
> Motivation: while privileged fscrypt key management is sufficient for
> some users (e.g. Android and Chromium OS, where a privileged process
> manages all keys), the old API by design also allows non-root users to
> set up and use encrypted directories, and we don't want to regress on
> that. Especially, we don't want to force users to continue using the
> old API, running into the visibility mismatch between files and keyrings
> and being unable to "lock" encrypted directories.
>
> Intuitively, the ioctls have to be privileged since they manipulate
> filesystem-level state. However, it's actually safe to make them
> unprivileged if we very carefully enforce some specific limitations.
>
> First, each key must be identified by a cryptographic hash so that a
> user can't add the wrong key for another user's files. For v2
> encryption policies, we use the key_identifier for this. v1 policies
> don't have this, so managing keys for them remains privileged.
>
> Second, each key a user adds is charged to their quota for the keyrings
> service. Thus, a user can't exhaust memory by adding a huge number of
> keys. By default each non-root user is allowed up to 200 keys; this can
> be changed using the existing sysctl 'kernel.keys.maxkeys'.
>
> Third, if multiple users add the same key, we keep track of those users
> of the key (of which there remains a single copy), and won't really
> remove the key, i.e. "lock" the encrypted files, until all those users
> have removed it. This prevents denial of service attacks that would be
> possible under simpler schemes, such allowing the first user who added a
> key to remove it -- since that could be a malicious user who has
> compromised the key. Of course, encryption keys should be kept secret,
> but the idea is that using encryption should never be *less* secure than
> not using encryption, even if your key was compromised.
>
> We tolerate that a user will be unable to really remove a key, i.e.
> unable to "lock" their encrypted files, if another user has added the
> same key. But in a sense, this is actually a good thing because it will
> avoid providing a false notion of security where a key appears to have
> been removed when actually it's still in memory, available to any
> attacker who compromises the operating system kernel.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Looks good. I'd probably would have used either "mk_secret_sem" or
"mk->mk_secret_sem" in the comments, instead of "->mk_securet_sem",
but that's just a personal style preference. Since you consistently
used the latter, I assume that's a deliberate choice, which is fine.
Feel free to add:
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Satya Tangirala <satyat@google.com>,
linux-api@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org, keyrings@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
linux-ext4@vger.kernel.org, Paul Crowley <paulcrowley@google.com>
Subject: Re: [PATCH v8 14/20] fscrypt: allow unprivileged users to add/remove keys for v2 policies
Date: Mon, 12 Aug 2019 20:14:07 -0400 [thread overview]
Message-ID: <20190813001406.GI28705@mit.edu> (raw)
In-Reply-To: <20190805162521.90882-15-ebiggers@kernel.org>
On Mon, Aug 05, 2019 at 09:25:15AM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> Allow the FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY
> ioctls to be used by non-root users to add and remove encryption keys
> from the filesystem-level crypto keyrings, subject to limitations.
>
> Motivation: while privileged fscrypt key management is sufficient for
> some users (e.g. Android and Chromium OS, where a privileged process
> manages all keys), the old API by design also allows non-root users to
> set up and use encrypted directories, and we don't want to regress on
> that. Especially, we don't want to force users to continue using the
> old API, running into the visibility mismatch between files and keyrings
> and being unable to "lock" encrypted directories.
>
> Intuitively, the ioctls have to be privileged since they manipulate
> filesystem-level state. However, it's actually safe to make them
> unprivileged if we very carefully enforce some specific limitations.
>
> First, each key must be identified by a cryptographic hash so that a
> user can't add the wrong key for another user's files. For v2
> encryption policies, we use the key_identifier for this. v1 policies
> don't have this, so managing keys for them remains privileged.
>
> Second, each key a user adds is charged to their quota for the keyrings
> service. Thus, a user can't exhaust memory by adding a huge number of
> keys. By default each non-root user is allowed up to 200 keys; this can
> be changed using the existing sysctl 'kernel.keys.maxkeys'.
>
> Third, if multiple users add the same key, we keep track of those users
> of the key (of which there remains a single copy), and won't really
> remove the key, i.e. "lock" the encrypted files, until all those users
> have removed it. This prevents denial of service attacks that would be
> possible under simpler schemes, such allowing the first user who added a
> key to remove it -- since that could be a malicious user who has
> compromised the key. Of course, encryption keys should be kept secret,
> but the idea is that using encryption should never be *less* secure than
> not using encryption, even if your key was compromised.
>
> We tolerate that a user will be unable to really remove a key, i.e.
> unable to "lock" their encrypted files, if another user has added the
> same key. But in a sense, this is actually a good thing because it will
> avoid providing a false notion of security where a key appears to have
> been removed when actually it's still in memory, available to any
> attacker who compromises the operating system kernel.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Looks good. I'd probably would have used either "mk_secret_sem" or
"mk->mk_secret_sem" in the comments, instead of "->mk_securet_sem",
but that's just a personal style preference. Since you consistently
used the latter, I assume that's a deliberate choice, which is fine.
Feel free to add:
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Satya Tangirala <satyat@google.com>,
linux-api@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org, keyrings@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
linux-ext4@vger.kernel.org, Paul Crowley <paulcrowley@google.com>
Subject: Re: [f2fs-dev] [PATCH v8 14/20] fscrypt: allow unprivileged users to add/remove keys for v2 policies
Date: Mon, 12 Aug 2019 20:14:07 -0400 [thread overview]
Message-ID: <20190813001406.GI28705@mit.edu> (raw)
In-Reply-To: <20190805162521.90882-15-ebiggers@kernel.org>
On Mon, Aug 05, 2019 at 09:25:15AM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> Allow the FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY
> ioctls to be used by non-root users to add and remove encryption keys
> from the filesystem-level crypto keyrings, subject to limitations.
>
> Motivation: while privileged fscrypt key management is sufficient for
> some users (e.g. Android and Chromium OS, where a privileged process
> manages all keys), the old API by design also allows non-root users to
> set up and use encrypted directories, and we don't want to regress on
> that. Especially, we don't want to force users to continue using the
> old API, running into the visibility mismatch between files and keyrings
> and being unable to "lock" encrypted directories.
>
> Intuitively, the ioctls have to be privileged since they manipulate
> filesystem-level state. However, it's actually safe to make them
> unprivileged if we very carefully enforce some specific limitations.
>
> First, each key must be identified by a cryptographic hash so that a
> user can't add the wrong key for another user's files. For v2
> encryption policies, we use the key_identifier for this. v1 policies
> don't have this, so managing keys for them remains privileged.
>
> Second, each key a user adds is charged to their quota for the keyrings
> service. Thus, a user can't exhaust memory by adding a huge number of
> keys. By default each non-root user is allowed up to 200 keys; this can
> be changed using the existing sysctl 'kernel.keys.maxkeys'.
>
> Third, if multiple users add the same key, we keep track of those users
> of the key (of which there remains a single copy), and won't really
> remove the key, i.e. "lock" the encrypted files, until all those users
> have removed it. This prevents denial of service attacks that would be
> possible under simpler schemes, such allowing the first user who added a
> key to remove it -- since that could be a malicious user who has
> compromised the key. Of course, encryption keys should be kept secret,
> but the idea is that using encryption should never be *less* secure than
> not using encryption, even if your key was compromised.
>
> We tolerate that a user will be unable to really remove a key, i.e.
> unable to "lock" their encrypted files, if another user has added the
> same key. But in a sense, this is actually a good thing because it will
> avoid providing a false notion of security where a key appears to have
> been removed when actually it's still in memory, available to any
> attacker who compromises the operating system kernel.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Looks good. I'd probably would have used either "mk_secret_sem" or
"mk->mk_secret_sem" in the comments, instead of "->mk_securet_sem",
but that's just a personal style preference. Since you consistently
used the latter, I assume that's a deliberate choice, which is fine.
Feel free to add:
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@kernel.org>
Cc: Satya Tangirala <satyat@google.com>,
linux-api@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org, keyrings@vger.kernel.org,
linux-mtd@lists.infradead.org, linux-crypto@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>,
linux-ext4@vger.kernel.org, Paul Crowley <paulcrowley@google.com>
Subject: Re: [PATCH v8 14/20] fscrypt: allow unprivileged users to add/remove keys for v2 policies
Date: Mon, 12 Aug 2019 20:14:07 -0400 [thread overview]
Message-ID: <20190813001406.GI28705@mit.edu> (raw)
In-Reply-To: <20190805162521.90882-15-ebiggers@kernel.org>
On Mon, Aug 05, 2019 at 09:25:15AM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
>
> Allow the FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY
> ioctls to be used by non-root users to add and remove encryption keys
> from the filesystem-level crypto keyrings, subject to limitations.
>
> Motivation: while privileged fscrypt key management is sufficient for
> some users (e.g. Android and Chromium OS, where a privileged process
> manages all keys), the old API by design also allows non-root users to
> set up and use encrypted directories, and we don't want to regress on
> that. Especially, we don't want to force users to continue using the
> old API, running into the visibility mismatch between files and keyrings
> and being unable to "lock" encrypted directories.
>
> Intuitively, the ioctls have to be privileged since they manipulate
> filesystem-level state. However, it's actually safe to make them
> unprivileged if we very carefully enforce some specific limitations.
>
> First, each key must be identified by a cryptographic hash so that a
> user can't add the wrong key for another user's files. For v2
> encryption policies, we use the key_identifier for this. v1 policies
> don't have this, so managing keys for them remains privileged.
>
> Second, each key a user adds is charged to their quota for the keyrings
> service. Thus, a user can't exhaust memory by adding a huge number of
> keys. By default each non-root user is allowed up to 200 keys; this can
> be changed using the existing sysctl 'kernel.keys.maxkeys'.
>
> Third, if multiple users add the same key, we keep track of those users
> of the key (of which there remains a single copy), and won't really
> remove the key, i.e. "lock" the encrypted files, until all those users
> have removed it. This prevents denial of service attacks that would be
> possible under simpler schemes, such allowing the first user who added a
> key to remove it -- since that could be a malicious user who has
> compromised the key. Of course, encryption keys should be kept secret,
> but the idea is that using encryption should never be *less* secure than
> not using encryption, even if your key was compromised.
>
> We tolerate that a user will be unable to really remove a key, i.e.
> unable to "lock" their encrypted files, if another user has added the
> same key. But in a sense, this is actually a good thing because it will
> avoid providing a false notion of security where a key appears to have
> been removed when actually it's still in memory, available to any
> attacker who compromises the operating system kernel.
>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Looks good. I'd probably would have used either "mk_secret_sem" or
"mk->mk_secret_sem" in the comments, instead of "->mk_securet_sem",
but that's just a personal style preference. Since you consistently
used the latter, I assume that's a deliberate choice, which is fine.
Feel free to add:
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2019-08-13 0:14 UTC|newest]
Thread overview: 162+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-05 16:25 [PATCH v8 00/20] fscrypt: key management improvements Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 01/20] fs, fscrypt: move uapi definitions to new header <linux/fscrypt.h> Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 02/20] fscrypt: use FSCRYPT_ prefix for uapi constants Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 03/20] fscrypt: use FSCRYPT_* definitions, not FS_* Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 04/20] fscrypt: add ->ci_inode to fscrypt_info Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 05/20] fscrypt: rename fscrypt_master_key to fscrypt_direct_key Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-12 22:20 ` Theodore Y. Ts'o
2019-08-12 22:20 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-12 22:20 ` Theodore Y. Ts'o
2019-08-12 22:20 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 06/20] fscrypt: refactor key setup code in preparation for v2 policies Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-12 22:38 ` Theodore Y. Ts'o
2019-08-12 22:38 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-12 22:38 ` Theodore Y. Ts'o
2019-08-12 22:38 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 07/20] fscrypt: move v1 policy key setup to keysetup_v1.c Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-12 22:53 ` Theodore Y. Ts'o
2019-08-12 22:53 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-12 22:53 ` Theodore Y. Ts'o
2019-08-12 22:53 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 08/20] fscrypt: rename keyinfo.c to keysetup.c Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-12 22:53 ` Theodore Y. Ts'o
2019-08-12 22:53 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-12 22:53 ` Theodore Y. Ts'o
2019-08-12 22:53 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 09/20] fscrypt: add FS_IOC_ADD_ENCRYPTION_KEY ioctl Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 10/20] fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY ioctl Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-13 0:06 ` Theodore Y. Ts'o
2019-08-13 0:06 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-13 0:06 ` Theodore Y. Ts'o
2019-08-13 0:06 ` Theodore Y. Ts'o
2019-08-14 22:35 ` Eric Biggers
2019-08-14 22:35 ` Eric Biggers
2019-08-14 22:35 ` Eric Biggers
2019-08-14 22:35 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 11/20] fscrypt: add FS_IOC_GET_ENCRYPTION_KEY_STATUS ioctl Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 12/20] fscrypt: add an HKDF-SHA512 implementation Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-06 20:43 ` Paul Crowley
2019-08-06 20:43 ` Paul Crowley
2019-08-06 20:43 ` [f2fs-dev] " Paul Crowley via Linux-f2fs-devel
2019-08-06 20:43 ` Paul Crowley via Linux-f2fs-devel
2019-08-06 20:43 ` Paul Crowley
2019-08-05 16:25 ` [PATCH v8 13/20] fscrypt: v2 encryption policy support Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-06 20:44 ` Paul Crowley
2019-08-06 20:44 ` Paul Crowley
2019-08-06 20:44 ` [f2fs-dev] " Paul Crowley via Linux-f2fs-devel
2019-08-06 20:44 ` Paul Crowley via Linux-f2fs-devel
2019-08-06 20:44 ` Paul Crowley
2019-08-13 0:39 ` Theodore Y. Ts'o
2019-08-13 0:39 ` Theodore Y. Ts'o
2019-08-13 0:39 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-13 0:39 ` Theodore Y. Ts'o
2019-08-13 0:39 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 14/20] fscrypt: allow unprivileged users to add/remove keys for v2 policies Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-13 0:14 ` Theodore Y. Ts'o [this message]
2019-08-13 0:14 ` Theodore Y. Ts'o
2019-08-13 0:14 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-13 0:14 ` Theodore Y. Ts'o
2019-08-13 0:14 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 15/20] fscrypt: add FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS ioctl Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-13 0:15 ` Theodore Y. Ts'o
2019-08-13 0:15 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-13 0:15 ` Theodore Y. Ts'o
2019-08-13 0:15 ` Theodore Y. Ts'o
2019-08-05 16:25 ` [PATCH v8 16/20] fscrypt: require that key be added when setting a v2 encryption policy Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 17/20] ext4: wire up new fscrypt ioctls Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 18/20] f2fs: " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` [PATCH v8 19/20] ubifs: " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [PATCH v8 20/20] fscrypt: document the new ioctls and policy version Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` [f2fs-dev] " Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-05 16:25 ` Eric Biggers
2019-08-13 0:49 ` Theodore Y. Ts'o
2019-08-13 0:49 ` Theodore Y. Ts'o
2019-08-13 0:49 ` [f2fs-dev] " Theodore Y. Ts'o
2019-08-13 0:49 ` Theodore Y. Ts'o
2019-08-13 0:49 ` Theodore Y. Ts'o
2019-08-14 22:37 ` [PATCH v8 00/20] fscrypt: key management improvements Eric Biggers
2019-08-14 22:37 ` [f2fs-dev] " Eric Biggers
2019-08-14 22:37 ` Eric Biggers
2019-08-14 22:37 ` 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=20190813001406.GI28705@mit.edu \
--to=tytso@mit.edu \
--cc=ebiggers@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=paulcrowley@google.com \
--cc=satyat@google.com \
/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.