aboutsummaryrefslogtreecommitdiffstats
path: root/fs/ecryptfs/ecryptfs_kernel.h
diff options
context:
space:
mode:
authorMichael Halcrow <mhalcrow@us.ibm.com>2007-02-12 03:53:43 -0500
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-02-12 12:48:36 -0500
commit88b4a07e6610f4c93b08b0bb103318218db1e9f6 (patch)
tree32e2f2650bd4841ba6b2fafc724c2806219351b4 /fs/ecryptfs/ecryptfs_kernel.h
parentb5d5dfbd59577aed72263f22e28d3eaf98e1c6e5 (diff)
[PATCH] eCryptfs: Public key transport mechanism
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. 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, which implements request packet parsing and manages PKI modules. libecryptfs grabs the public key authentication token for the given signature from the user session keyring. This auth tok tells libecryptfs which PKI module should receive the request. libecryptfs then makes a decrypt() call to the PKI module, and it passes along the PKI block from the auth tok. The PKI uses the blob to figure out how it should decrypt the data passed to it; it performs the decryption and passes the decrypted data back to libecryptfs. libecryptfs then puts together a reply packet with the decrypted FEK and passes that back to the eCryptfs module. The eCryptfs module manages these request callouts to userspace code via message context structs. The module maintains an array of message context structs and places the elements of the array on two lists: a free and an allocated list. When eCryptfs wants to make a request, it moves a msg ctx from the free list to the allocated list, sets its state to pending, and fires off the message to the user's registered daemon. When eCryptfs receives a netlink message (via the callback), it correlates the msg ctx struct in the alloc list with the data in the message itself. The msg->index contains the offset of the array of msg ctx structs. It verifies that the registered daemon PID is the same as the PID of the process that sent the message. It also validates a sequence number between the received packet and the msg ctx. Then, it copies the contents of the message (the reply packet) into the msg ctx struct, sets the state in the msg ctx to done, and wakes up the process that was sleeping while waiting for the reply. The sleeping process was whatever was performing the sys_open(). This process originally called ecryptfs_send_message(); it is now in ecryptfs_wait_for_response(). When it wakes up and sees that the msg ctx state was set to done, it returns a pointer to the message contents (the reply packet) and returns. If all went well, this packet contains the decrypted FEK, which is then copied into the crypt_stat struct, and life continues as normal. The case for creation of a new file is very similar, only instead of a decrypt request, eCryptfs sends out an encrypt request. > - We have a great clod of key mangement code in-kernel. Why is that > not suitable (or growable) for public key management? eCryptfs uses Howells' keyring to store persistent key data and PKI state information. It defers public key cryptographic transformations to userspace code. The userspace data manipulation request really is orthogonal to key management in and of itself. What eCryptfs basically needs is a secure way to communicate with a particular daemon for a particular task doing a syscall, based on the UID. Nothing running under another UID should be able to access that channel of communication. > - Is it appropriate that new infrastructure for public key > management be private to a particular fs? The messaging.c file contains a lot of code that, perhaps, could be extracted into a separate kernel service. In essence, this would be a sort of request/reply mechanism that would involve a userspace daemon. I am not aware of anything that does quite what eCryptfs does, so I was not aware of any existing tools to do just what we wanted. > What happens if one of these daemons exits without sending a quit > message? There is a stale uid<->pid association in the hash table for that user. When the user registers a new daemon, eCryptfs cleans up the old association and generates a new one. See ecryptfs_process_helo(). > - _why_ does it use netlink? Netlink provides the transport mechanism that would minimize the complexity of the implementation, given that we can have multiple daemons (one per user). I explored the possibility of using relayfs, but that would involve having to introduce control channels and a protocol for creating and tearing down channels for the daemons. We do not have to worry about any of that with netlink. Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com> Cc: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs/ecryptfs/ecryptfs_kernel.h')
-rw-r--r--fs/ecryptfs/ecryptfs_kernel.h101
1 files changed, 98 insertions, 3 deletions
diff --git a/fs/ecryptfs/ecryptfs_kernel.h b/fs/ecryptfs/ecryptfs_kernel.h
index 0f897109759b..508648efa447 100644
--- a/fs/ecryptfs/ecryptfs_kernel.h
+++ b/fs/ecryptfs/ecryptfs_kernel.h
@@ -6,6 +6,8 @@
6 * Copyright (C) 2001-2003 Stony Brook University 6 * Copyright (C) 2001-2003 Stony Brook University
7 * Copyright (C) 2004-2006 International Business Machines Corp. 7 * Copyright (C) 2004-2006 International Business Machines Corp.
8 * Author(s): Michael A. Halcrow <mahalcro@us.ibm.com> 8 * Author(s): Michael A. Halcrow <mahalcro@us.ibm.com>
9 * Trevor S. Highland <trevor.highland@gmail.com>
10 * Tyler Hicks <tyhicks@ou.edu>
9 * 11 *
10 * This program is free software; you can redistribute it and/or 12 * This program is free software; you can redistribute it and/or
11 * modify it under the terms of the GNU General Public License as 13 * modify it under the terms of the GNU General Public License as
@@ -35,7 +37,7 @@
35/* Version verification for shared data structures w/ userspace */ 37/* Version verification for shared data structures w/ userspace */
36#define ECRYPTFS_VERSION_MAJOR 0x00 38#define ECRYPTFS_VERSION_MAJOR 0x00
37#define ECRYPTFS_VERSION_MINOR 0x04 39#define ECRYPTFS_VERSION_MINOR 0x04
38#define ECRYPTFS_SUPPORTED_FILE_VERSION 0x01 40#define ECRYPTFS_SUPPORTED_FILE_VERSION 0x02
39/* These flags indicate which features are supported by the kernel 41/* These flags indicate which features are supported by the kernel
40 * module; userspace tools such as the mount helper read 42 * module; userspace tools such as the mount helper read
41 * ECRYPTFS_VERSIONING_MASK from a sysfs handle in order to determine 43 * ECRYPTFS_VERSIONING_MASK from a sysfs handle in order to determine
@@ -60,10 +62,24 @@
60#define ECRYPTFS_MAX_KEY_BYTES 64 62#define ECRYPTFS_MAX_KEY_BYTES 64
61#define ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES 512 63#define ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES 512
62#define ECRYPTFS_DEFAULT_IV_BYTES 16 64#define ECRYPTFS_DEFAULT_IV_BYTES 16
63#define ECRYPTFS_FILE_VERSION 0x01 65#define ECRYPTFS_FILE_VERSION 0x02
64#define ECRYPTFS_DEFAULT_HEADER_EXTENT_SIZE 8192 66#define ECRYPTFS_DEFAULT_HEADER_EXTENT_SIZE 8192
65#define ECRYPTFS_DEFAULT_EXTENT_SIZE 4096 67#define ECRYPTFS_DEFAULT_EXTENT_SIZE 4096
66#define ECRYPTFS_MINIMUM_HEADER_EXTENT_SIZE 8192 68#define ECRYPTFS_MINIMUM_HEADER_EXTENT_SIZE 8192
69#define ECRYPTFS_DEFAULT_MSG_CTX_ELEMS 32
70#define ECRYPTFS_DEFAULT_SEND_TIMEOUT HZ
71#define ECRYPTFS_MAX_MSG_CTX_TTL (HZ*3)
72#define ECRYPTFS_NLMSG_HELO 100
73#define ECRYPTFS_NLMSG_QUIT 101
74#define ECRYPTFS_NLMSG_REQUEST 102
75#define ECRYPTFS_NLMSG_RESPONSE 103
76#define ECRYPTFS_MAX_PKI_NAME_BYTES 16
77#define ECRYPTFS_DEFAULT_NUM_USERS 4
78#define ECRYPTFS_MAX_NUM_USERS 32768
79#define ECRYPTFS_TRANSPORT_NETLINK 0
80#define ECRYPTFS_TRANSPORT_CONNECTOR 1
81#define ECRYPTFS_TRANSPORT_RELAYFS 2
82#define ECRYPTFS_DEFAULT_TRANSPORT ECRYPTFS_TRANSPORT_NETLINK
67 83
68#define RFC2440_CIPHER_DES3_EDE 0x02 84#define RFC2440_CIPHER_DES3_EDE 0x02
69#define RFC2440_CIPHER_CAST_5 0x03 85#define RFC2440_CIPHER_CAST_5 0x03
@@ -77,6 +93,7 @@
77#define ECRYPTFS_SET_FLAG(flag_bit_vector, flag) (flag_bit_vector |= (flag)) 93#define ECRYPTFS_SET_FLAG(flag_bit_vector, flag) (flag_bit_vector |= (flag))
78#define ECRYPTFS_CLEAR_FLAG(flag_bit_vector, flag) (flag_bit_vector &= ~(flag)) 94#define ECRYPTFS_CLEAR_FLAG(flag_bit_vector, flag) (flag_bit_vector &= ~(flag))
79#define ECRYPTFS_CHECK_FLAG(flag_bit_vector, flag) (flag_bit_vector & (flag)) 95#define ECRYPTFS_CHECK_FLAG(flag_bit_vector, flag) (flag_bit_vector & (flag))
96#define RFC2440_CIPHER_RSA 0x01
80 97
81/** 98/**
82 * For convenience, we may need to pass around the encrypted session 99 * For convenience, we may need to pass around the encrypted session
@@ -114,6 +131,14 @@ struct ecryptfs_password {
114 131
115enum ecryptfs_token_types {ECRYPTFS_PASSWORD, ECRYPTFS_PRIVATE_KEY}; 132enum ecryptfs_token_types {ECRYPTFS_PASSWORD, ECRYPTFS_PRIVATE_KEY};
116 133
134struct ecryptfs_private_key {
135 u32 key_size;
136 u32 data_len;
137 u8 signature[ECRYPTFS_PASSWORD_SIG_SIZE + 1];
138 char pki_type[ECRYPTFS_MAX_PKI_NAME_BYTES + 1];
139 u8 data[];
140};
141
117/* May be a password or a private key */ 142/* May be a password or a private key */
118struct ecryptfs_auth_tok { 143struct ecryptfs_auth_tok {
119 u16 version; /* 8-bit major and 8-bit minor */ 144 u16 version; /* 8-bit major and 8-bit minor */
@@ -123,7 +148,7 @@ struct ecryptfs_auth_tok {
123 u8 reserved[32]; 148 u8 reserved[32];
124 union { 149 union {
125 struct ecryptfs_password password; 150 struct ecryptfs_password password;
126 /* Private key is in future eCryptfs releases */ 151 struct ecryptfs_private_key private_key;
127 } token; 152 } token;
128} __attribute__ ((packed)); 153} __attribute__ ((packed));
129 154
@@ -177,8 +202,13 @@ ecryptfs_get_key_payload_data(struct key *key)
177#define ECRYPTFS_DEFAULT_CIPHER "aes" 202#define ECRYPTFS_DEFAULT_CIPHER "aes"
178#define ECRYPTFS_DEFAULT_KEY_BYTES 16 203#define ECRYPTFS_DEFAULT_KEY_BYTES 16
179#define ECRYPTFS_DEFAULT_HASH "md5" 204#define ECRYPTFS_DEFAULT_HASH "md5"
205#define ECRYPTFS_TAG_1_PACKET_TYPE 0x01
180#define ECRYPTFS_TAG_3_PACKET_TYPE 0x8C 206#define ECRYPTFS_TAG_3_PACKET_TYPE 0x8C
181#define ECRYPTFS_TAG_11_PACKET_TYPE 0xED 207#define ECRYPTFS_TAG_11_PACKET_TYPE 0xED
208#define ECRYPTFS_TAG_64_PACKET_TYPE 0x40
209#define ECRYPTFS_TAG_65_PACKET_TYPE 0x41
210#define ECRYPTFS_TAG_66_PACKET_TYPE 0x42
211#define ECRYPTFS_TAG_67_PACKET_TYPE 0x43
182#define MD5_DIGEST_SIZE 16 212#define MD5_DIGEST_SIZE 16
183 213
184/** 214/**
@@ -271,6 +301,45 @@ struct ecryptfs_auth_tok_list_item {
271 struct ecryptfs_auth_tok auth_tok; 301 struct ecryptfs_auth_tok auth_tok;
272}; 302};
273 303
304struct ecryptfs_message {
305 u32 index;
306 u32 data_len;
307 u8 data[];
308};
309
310struct ecryptfs_msg_ctx {
311#define ECRYPTFS_MSG_CTX_STATE_FREE 0x0001
312#define ECRYPTFS_MSG_CTX_STATE_PENDING 0x0002
313#define ECRYPTFS_MSG_CTX_STATE_DONE 0x0003
314 u32 state;
315 unsigned int index;
316 unsigned int counter;
317 struct ecryptfs_message *msg;
318 struct task_struct *task;
319 struct list_head node;
320 struct mutex mux;
321};
322
323extern struct list_head ecryptfs_msg_ctx_free_list;
324extern struct list_head ecryptfs_msg_ctx_alloc_list;
325extern struct mutex ecryptfs_msg_ctx_lists_mux;
326
327#define ecryptfs_uid_hash(uid) \
328 hash_long((unsigned long)uid, ecryptfs_hash_buckets)
329extern struct hlist_head *ecryptfs_daemon_id_hash;
330extern struct mutex ecryptfs_daemon_id_hash_mux;
331extern int ecryptfs_hash_buckets;
332
333extern unsigned int ecryptfs_msg_counter;
334extern struct ecryptfs_msg_ctx *ecryptfs_msg_ctx_arr;
335extern unsigned int ecryptfs_transport;
336
337struct ecryptfs_daemon_id {
338 pid_t pid;
339 uid_t uid;
340 struct hlist_node id_chain;
341};
342
274static inline struct ecryptfs_file_info * 343static inline struct ecryptfs_file_info *
275ecryptfs_file_to_private(struct file *file) 344ecryptfs_file_to_private(struct file *file)
276{ 345{
@@ -391,6 +460,9 @@ extern struct super_operations ecryptfs_sops;
391extern struct dentry_operations ecryptfs_dops; 460extern struct dentry_operations ecryptfs_dops;
392extern struct address_space_operations ecryptfs_aops; 461extern struct address_space_operations ecryptfs_aops;
393extern int ecryptfs_verbosity; 462extern int ecryptfs_verbosity;
463extern unsigned int ecryptfs_message_buf_len;
464extern signed long ecryptfs_message_wait_timeout;
465extern unsigned int ecryptfs_number_of_users;
394 466
395extern struct kmem_cache *ecryptfs_auth_tok_list_item_cache; 467extern struct kmem_cache *ecryptfs_auth_tok_list_item_cache;
396extern struct kmem_cache *ecryptfs_file_info_cache; 468extern struct kmem_cache *ecryptfs_file_info_cache;
@@ -484,4 +556,27 @@ int ecryptfs_open_lower_file(struct file **lower_file,
484 struct vfsmount *lower_mnt, int flags); 556 struct vfsmount *lower_mnt, int flags);
485int ecryptfs_close_lower_file(struct file *lower_file); 557int ecryptfs_close_lower_file(struct file *lower_file);
486 558
559int ecryptfs_process_helo(unsigned int transport, uid_t uid, pid_t pid);
560int ecryptfs_process_quit(uid_t uid, pid_t pid);
561int ecryptfs_process_response(struct ecryptfs_message *msg, pid_t pid, u32 seq);
562int ecryptfs_send_message(unsigned int transport, char *data, int data_len,
563 struct ecryptfs_msg_ctx **msg_ctx);
564int ecryptfs_wait_for_response(struct ecryptfs_msg_ctx *msg_ctx,
565 struct ecryptfs_message **emsg);
566int ecryptfs_init_messaging(unsigned int transport);
567void ecryptfs_release_messaging(unsigned int transport);
568
569int ecryptfs_send_netlink(char *data, int data_len,
570 struct ecryptfs_msg_ctx *msg_ctx, u16 msg_type,
571 u16 msg_flags, pid_t daemon_pid);
572int ecryptfs_init_netlink(void);
573void ecryptfs_release_netlink(void);
574
575int ecryptfs_send_connector(char *data, int data_len,
576 struct ecryptfs_msg_ctx *msg_ctx, u16 msg_type,
577 u16 msg_flags, pid_t daemon_pid);
578int ecryptfs_init_connector(void);
579void ecryptfs_release_connector(void);
580
581
487#endif /* #ifndef ECRYPTFS_KERNEL_H */ 582#endif /* #ifndef ECRYPTFS_KERNEL_H */