Re: [PATCH 1/2] eCryptfs: Public key; transport mechanism
On Sat, Dec 09, 2006 at 11:21:30AM -0800, Andrew Morton wrote: > On Sat, 9 Dec 2006 11:04:16 -0800 > Randy Dunlap <[EMAIL PROTECTED]> wrote: > > > ecryptfs now has a dependency upon netlink. There's no > > > CONFIG_NETLINK. If CONFIG_NET=n && CONFIG_ECRYPTFS=y is > > > possible, it won't build. > > > > Then shouldn't ECRYPTFS depend on CONFIG_NET ? > > yup, that's what I meant.. Add net build dependency to eCryptfs Kconfig entry. Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]> --- fs/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) b2bc2515b6849154a9598bca4975dc721799954c diff --git a/fs/Kconfig b/fs/Kconfig index c93d82b..17ae291 100644 --- a/fs/Kconfig +++ b/fs/Kconfig @@ -1103,7 +1103,7 @@ config AFFS_FS config ECRYPT_FS tristate "eCrypt filesystem layer support (EXPERIMENTAL)" - depends on EXPERIMENTAL && KEYS && CRYPTO + depends on EXPERIMENTAL && KEYS && CRYPTO && NET help Encrypted filesystem that operates on the VFS layer. See to learn more about -- 1.3.3 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] eCryptfs: Public key; transport mechanism
Andrew Morton wrote: On Sat, 9 Dec 2006 11:04:16 -0800 Randy Dunlap <[EMAIL PROTECTED]> wrote: ecryptfs now has a dependency upon netlink. There's no CONFIG_NETLINK. If CONFIG_NET=n && CONFIG_ECRYPTFS=y is possible, it won't build. Then shouldn't ECRYPTFS depend on CONFIG_NET ? yup, that's what I meant.. That's easy enough to fix, but I was hoping that driver or filesystem maintainers would eventually use & heed Documentation/SubmitChecklist. :( -- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] eCryptfs: Public key; transport mechanism
On Sat, 9 Dec 2006 11:04:16 -0800 Randy Dunlap <[EMAIL PROTECTED]> wrote: > > ecryptfs now has a dependency upon netlink. There's no CONFIG_NETLINK. If > > CONFIG_NET=n && CONFIG_ECRYPTFS=y is possible, it won't build. > > Then shouldn't ECRYPTFS depend on CONFIG_NET ? yup, that's what I meant.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] eCryptfs: Public key; transport mechanism
On Wed, 6 Dec 2006 21:55:55 -0800 Andrew Morton wrote: > On Wed, 6 Dec 2006 17:06:38 -0600 > Michael Halcrow <[EMAIL PROTECTED]> wrote: > > > This is a re-submission of the same public key patches (updated for > > 2.6.19-rc6-mm2) that were submitted for review a while back. > > I made a number of comments last time around, some temperate, some not. > I trust the temperate ones were addressed? > > Is there really no way in which any other kernel subsystem will ever want > functionality of this nature? > > > This is the transport code for public key functionality in > > eCryptfs. It manages encryption/decryption request queues with a > > transport mechanism. Currently, netlink is the only implemented > > transport. > > I wouldn't view this as an adequate changelog for this sort of work, > frankly. Not by a long shot. You've told us very briefly what the patches > do. You haven't told us why they do it, nor how they do it. > > What design decisions went into this? What options were considered and > eliminated and why? etc. > > It's just a great lump of code dumped in our laps. > > > >From a quick scan (and I cannot review in more depth because the code is a > complete mystery to this reviewer): > > > > + mutex_init(&ecryptfs_msg_ctx_lists_mux); > > + mutex_lock(&ecryptfs_msg_ctx_lists_mux); > > That's a bizarre thing to do. If there's really any other process which > can take that mutex, the mutex_init() just trashed it. If there is no > other such process, the mutex_lock() is unneeded. There should never be > a need to runtime-initialise a static mutex - just use DEFINE_MUTEX. > > > ecryptfs now has a dependency upon netlink. There's no CONFIG_NETLINK. If > CONFIG_NET=n && CONFIG_ECRYPTFS=y is possible, it won't build. Then shouldn't ECRYPTFS depend on CONFIG_NET ? --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] eCryptfs: Public key; transport mechanism
On Wed, Dec 06, 2006 at 09:55:55PM -0800, Andrew Morton wrote: > On Wed, 6 Dec 2006 17:06:38 -0600 > Michael Halcrow <[EMAIL PROTECTED]> wrote: > > > This is a re-submission of the same public key patches (updated for > > 2.6.19-rc6-mm2) that were submitted for review a while back. > > I made a number of comments last time around, some temperate, some not. > I trust the temperate ones were addressed? > > Is there really no way in which any other kernel subsystem will ever want > functionality of this nature? > > > This is the transport code for public key functionality in > > eCryptfs. It manages encryption/decryption request queues with a > > transport mechanism. Currently, netlink is the only implemented > > transport. > > I wouldn't view this as an adequate changelog for this sort of work, > frankly. Not by a long shot. You've told us very briefly what the patches > do. You haven't told us why they do it, nor how they do it. > > What design decisions went into this? What options were considered and > eliminated and why? etc. > > It's just a great lump of code dumped in our laps. Here is the longer description of the patches that I sent back in August. These comments still apply to the current public key patches. I apologize for not including this content again in the recent submission. I agree that the messaging code might be of use elsewhere in the kernel in the future. If other kernel developers think that what eCryptfs does for messaging with a userspace daemon is sane, then I can get to work on a patch to extract that into a more general-purpose function. Mike - Forwarded message from Michael Halcrow <[EMAIL PROTECTED]> - From: Michael Halcrow <[EMAIL PROTECTED]> To: Andrew Morton <[EMAIL PROTECTED]> Cc: linux-kernel@vger.kernel.org, [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [PATCH 1/4] eCryptfs: Netlink functions for public key Reply-To: Michael Halcrow <[EMAIL PROTECTED]> On Thu, Aug 24, 2006 at 08:54:19PM -0700, Andrew Morton wrote: > On Thu, 24 Aug 2006 13:18:32 -0500 > Michael Halcrow <[EMAIL PROTECTED]> wrote: > > eCryptfs netlink type, header updates, and messaging code to > > provide support for userspace callout to perform public key > > operations. > > That tells us (with maximum terseness) what it does. We're left to > our own devices to work out why it does this, how it does it and why > it does it in the way in which it does it? This leads to dumb > questions ;) There is a design document in the works; it's in the ecryptfs-util userspace tarball, under doc/design_doc/. It still needs some fleshing out to encompass userspace components. I'll go ahead and summarize the design for this patch set. Each inode has a unique File Encryption Key (FEK). Under passphrase, a File Encryption Key Encryption Key (FEKEK) is generated from a salt/passphrase combo on mount. This FEKEK encrypts each FEK and writes it into the header of each file using the packet format specified in RFC 2440. This is all symmetric key encryption, so it can all be done via the kernel crypto API. These new patches introduce public key encryption of the FEK. There is no asymmetric key encryption support in the kernel crypto API, so eCryptfs pushes the FEK encryption and decryption out to a userspace daemon. After considering our requirements and determining the complexity of using various transport mechanisms, we settled on netlink for this communication. eCryptfs stores authentication tokens into the kernel keyring. These tokens correlate with individual keys. For passphrase mode of operation, the authentication token contains the symmetric FEKEK. For public key, the authentication token contains a PKI type and an opaque data blob managed by individual PKI modules in userspace. Each user who opens a file under an eCryptfs partition mounted in public key mode must be running a daemon. That daemon has the user's credentials and has access to all of the keys to which the user should have access. The daemon, when started, initializes the pluggable PKI modules available on the system and registers itself with the eCryptfs kernel module. Userspace utilities register public key authentication tokens into the user session keyring. These authentication tokens correlate key signatures with PKI modules and PKI blobs. The PKI blobs contain PKI-specific information necessary for the PKI module to carry out asymmetric key encryption and decryption. When the eCryptfs module parses the header of an existing file and finds a Tag 1 (Public Key) packet (see RFC 2440), it reads in the public key identifier (signature). The asymmetrically encrypted FEK is in the Tag 1 packet; eCryptfs puts together a decrypt request packet containing the signature and the encrypted FEK, then it passes it to the daemon registered for the current->euid via a netlink unicast to the PID of the daemon, which was registered at the time the daemon was started by the user. The daemon actually just makes calls to libecryptfs, wh
Re: [PATCH 1/2] eCryptfs: Public key; transport mechanism
On Wed, 6 Dec 2006 17:06:38 -0600 Michael Halcrow <[EMAIL PROTECTED]> wrote: > This is a re-submission of the same public key patches (updated for > 2.6.19-rc6-mm2) that were submitted for review a while back. I made a number of comments last time around, some temperate, some not. I trust the temperate ones were addressed? Is there really no way in which any other kernel subsystem will ever want functionality of this nature? > This is the transport code for public key functionality in > eCryptfs. It manages encryption/decryption request queues with a > transport mechanism. Currently, netlink is the only implemented > transport. I wouldn't view this as an adequate changelog for this sort of work, frankly. Not by a long shot. You've told us very briefly what the patches do. You haven't told us why they do it, nor how they do it. What design decisions went into this? What options were considered and eliminated and why? etc. It's just a great lump of code dumped in our laps. >From a quick scan (and I cannot review in more depth because the code is a complete mystery to this reviewer): > + mutex_init(&ecryptfs_msg_ctx_lists_mux); > + mutex_lock(&ecryptfs_msg_ctx_lists_mux); That's a bizarre thing to do. If there's really any other process which can take that mutex, the mutex_init() just trashed it. If there is no other such process, the mutex_lock() is unneeded. There should never be a need to runtime-initialise a static mutex - just use DEFINE_MUTEX. ecryptfs now has a dependency upon netlink. There's no CONFIG_NETLINK. If CONFIG_NET=n && CONFIG_ECRYPTFS=y is possible, it won't build. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] eCryptfs: Public key; transport mechanism
This is a re-submission of the same public key patches (updated for
2.6.19-rc6-mm2) that were submitted for review a while back.
This is the transport code for public key functionality in
eCryptfs. It manages encryption/decryption request queues with a
transport mechanism. Currently, netlink is the only implemented
transport.
Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]>
---
fs/ecryptfs/ecryptfs_kernel.h | 101
fs/ecryptfs/messaging.c | 505 +
fs/ecryptfs/netlink.c | 255 +
include/linux/netlink.h |1
4 files changed, 859 insertions(+), 3 deletions(-)
create mode 100644 fs/ecryptfs/messaging.c
create mode 100644 fs/ecryptfs/netlink.c
fa0a4f8f4601b6c005fcaa628f2d74c6466ec54d
diff --git a/fs/ecryptfs/ecryptfs_kernel.h b/fs/ecryptfs/ecryptfs_kernel.h
index 870a65b..2bae036 100644
--- a/fs/ecryptfs/ecryptfs_kernel.h
+++ b/fs/ecryptfs/ecryptfs_kernel.h
@@ -6,6 +6,8 @@
* Copyright (C) 2001-2003 Stony Brook University
* Copyright (C) 2004-2006 International Business Machines Corp.
* Author(s): Michael A. Halcrow <[EMAIL PROTECTED]>
+ * Trevor S. Highland <[EMAIL PROTECTED]>
+ * Tyler Hicks <[EMAIL PROTECTED]>
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
@@ -34,7 +36,7 @@ #include
/* Version verification for shared data structures w/ userspace */
#define ECRYPTFS_VERSION_MAJOR 0x00
#define ECRYPTFS_VERSION_MINOR 0x04
-#define ECRYPTFS_SUPPORTED_FILE_VERSION 0x01
+#define ECRYPTFS_SUPPORTED_FILE_VERSION 0x02
/* These flags indicate which features are supported by the kernel
* module; userspace tools such as the mount helper read
* ECRYPTFS_VERSIONING_MASK from a sysfs handle in order to determine
@@ -59,10 +61,24 @@ #define ECRYPTFS_PASSWORD_SIG_SIZE ECRYP
#define ECRYPTFS_MAX_KEY_BYTES 64
#define ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES 512
#define ECRYPTFS_DEFAULT_IV_BYTES 16
-#define ECRYPTFS_FILE_VERSION 0x01
+#define ECRYPTFS_FILE_VERSION 0x02
#define ECRYPTFS_DEFAULT_HEADER_EXTENT_SIZE 8192
#define ECRYPTFS_DEFAULT_EXTENT_SIZE 4096
#define ECRYPTFS_MINIMUM_HEADER_EXTENT_SIZE 8192
+#define ECRYPTFS_DEFAULT_MSG_CTX_ELEMS 32
+#define ECRYPTFS_DEFAULT_SEND_TIMEOUT HZ
+#define ECRYPTFS_MAX_MSG_CTX_TTL (HZ*3)
+#define ECRYPTFS_NLMSG_HELO 100
+#define ECRYPTFS_NLMSG_QUIT 101
+#define ECRYPTFS_NLMSG_REQUEST 102
+#define ECRYPTFS_NLMSG_RESPONSE 103
+#define ECRYPTFS_MAX_PKI_NAME_BYTES 16
+#define ECRYPTFS_DEFAULT_NUM_USERS 4
+#define ECRYPTFS_MAX_NUM_USERS 32768
+#define ECRYPTFS_TRANSPORT_NETLINK 0
+#define ECRYPTFS_TRANSPORT_CONNECTOR 1
+#define ECRYPTFS_TRANSPORT_RELAYFS 2
+#define ECRYPTFS_DEFAULT_TRANSPORT ECRYPTFS_TRANSPORT_NETLINK
#define RFC2440_CIPHER_DES3_EDE 0x02
#define RFC2440_CIPHER_CAST_5 0x03
@@ -76,6 +92,7 @@ #define RFC2440_CIPHER_CAST_6 0x0b
#define ECRYPTFS_SET_FLAG(flag_bit_vector, flag) (flag_bit_vector |= (flag))
#define ECRYPTFS_CLEAR_FLAG(flag_bit_vector, flag) (flag_bit_vector &= ~(flag))
#define ECRYPTFS_CHECK_FLAG(flag_bit_vector, flag) (flag_bit_vector & (flag))
+#define RFC2440_CIPHER_RSA 0x01
/**
* For convenience, we may need to pass around the encrypted session
@@ -113,6 +130,14 @@ #define ECRYPTFS_SESSION_KEY_ENCRYPTION_
enum ecryptfs_token_types {ECRYPTFS_PASSWORD, ECRYPTFS_PRIVATE_KEY};
+struct ecryptfs_private_key {
+ u32 key_size;
+ u32 data_len;
+ u8 signature[ECRYPTFS_PASSWORD_SIG_SIZE + 1];
+ char pki_type[ECRYPTFS_MAX_PKI_NAME_BYTES + 1];
+ u8 data[];
+};
+
/* May be a password or a private key */
struct ecryptfs_auth_tok {
u16 version; /* 8-bit major and 8-bit minor */
@@ -122,7 +147,7 @@ struct ecryptfs_auth_tok {
u8 reserved[32];
union {
struct ecryptfs_password password;
- /* Private key is in future eCryptfs releases */
+ struct ecryptfs_private_key private_key;
} token;
} __attribute__ ((packed));
@@ -177,8 +202,13 @@ #define ECRYPTFS_DEFAULT_CIPHER "aes"
#define ECRYPTFS_DEFAULT_KEY_BYTES 16
#define ECRYPTFS_DEFAULT_CHAINING_MODE CRYPTO_TFM_MODE_CBC
#define ECRYPTFS_DEFAULT_HASH "md5"
+#define ECRYPTFS_TAG_1_PACKET_TYPE 0x01
#define ECRYPTFS_TAG_3_PACKET_TYPE 0x8C
#define ECRYPTFS_TAG_11_PACKET_TYPE 0xED
+#define ECRYPTFS_TAG_64_PACKET_TYPE 0x40
+#define ECRYPTFS_TAG_65_PACKET_TYPE 0x41
+#define ECRYPTFS_TAG_66_PACKET_TYPE 0x42
+#define ECRYPTFS_TAG_67_PACKET_TYPE 0x43
#define MD5_DIGEST_SIZE 16
/**
@@ -271,6 +301,45 @@ struct ecryptfs_auth_tok_list_item {
struct ecryptfs_auth_tok auth_tok;
};
+struct ecryptfs_message {
+ u32 index;
+ u32 data_len;
+ u8 data[];
+};
+
+struct ecryptfs_msg_ctx {
+#define ECRYPTFS_MSG_CTX_STATE_FREE 0x0001
+#define ECRYPTFS_MSG_CTX_STATE_PENDING 0x0002
+#define ECRYPTFS_MSG_CTX_STATE_DONE 0x0003
+ u32 state;
+ unsig
