2006-10-04 09:16:22 +00:00
|
|
|
/**
|
|
|
|
|
* eCryptfs: Linux filesystem encryption layer
|
|
|
|
|
* Kernel declarations.
|
|
|
|
|
*
|
|
|
|
|
* Copyright (C) 1997-2003 Erez Zadok
|
|
|
|
|
* Copyright (C) 2001-2003 Stony Brook University
|
2007-02-12 08:53:46 +00:00
|
|
|
* Copyright (C) 2004-2007 International Business Machines Corp.
|
2006-10-04 09:16:22 +00:00
|
|
|
* Author(s): Michael A. Halcrow <mahalcro@us.ibm.com>
|
[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>
2007-02-12 08:53:43 +00:00
|
|
|
* Trevor S. Highland <trevor.highland@gmail.com>
|
|
|
|
|
* Tyler Hicks <tyhicks@ou.edu>
|
2006-10-04 09:16:22 +00:00
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
|
* modify it under the terms of the GNU General Public License as
|
|
|
|
|
* published by the Free Software Foundation; either version 2 of the
|
|
|
|
|
* License, or (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful, but
|
|
|
|
|
* WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
|
* General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
|
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
|
|
|
|
|
* 02111-1307, USA.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#ifndef ECRYPTFS_KERNEL_H
|
|
|
|
|
#define ECRYPTFS_KERNEL_H
|
|
|
|
|
|
|
|
|
|
#include <keys/user-type.h>
|
|
|
|
|
#include <linux/fs.h>
|
2006-12-08 10:36:31 +00:00
|
|
|
#include <linux/fs_stack.h>
|
2006-12-08 10:36:34 +00:00
|
|
|
#include <linux/namei.h>
|
2006-10-04 09:16:22 +00:00
|
|
|
#include <linux/scatterlist.h>
|
2007-02-12 08:53:44 +00:00
|
|
|
#include <linux/hash.h>
|
2006-10-04 09:16:22 +00:00
|
|
|
|
|
|
|
|
/* Version verification for shared data structures w/ userspace */
|
|
|
|
|
#define ECRYPTFS_VERSION_MAJOR 0x00
|
|
|
|
|
#define ECRYPTFS_VERSION_MINOR 0x04
|
[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>
2007-02-12 08:53:43 +00:00
|
|
|
#define ECRYPTFS_SUPPORTED_FILE_VERSION 0x02
|
2006-10-04 09:16:22 +00:00
|
|
|
/* 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
|
|
|
|
|
* how to behave. */
|
[PATCH] eCryptfs: xattr flags and mount options
This patch set introduces the ability to store cryptographic metadata into an
lower file extended attribute rather than the lower file header region.
This patch set implements two new mount options:
ecryptfs_xattr_metadata
- When set, newly created files will have their cryptographic
metadata stored in the extended attribute region of the file rather
than the header.
When storing the data in the file header, there is a minimum of 8KB
reserved for the header information for each file, making each file at
least 12KB in size. This can take up a lot of extra disk space if the user
creates a lot of small files. By storing the data in the extended
attribute, each file will only occupy at least of 4KB of space.
As the eCryptfs metadata set becomes larger with new features such as
multi-key associations, most popular filesystems will not be able to store
all of the information in the xattr region in some cases due to space
constraints. However, the majority of users will only ever associate one
key per file, so most users will be okay with storing their data in the
xattr region.
This option should be used with caution. I want to emphasize that the
xattr must be maintained under all circumstances, or the file will be
rendered permanently unrecoverable. The last thing I want is for a user to
forget to set an xattr flag in a backup utility, only to later discover
that their backups are worthless.
ecryptfs_encrypted_view
- When set, this option causes eCryptfs to present applications a
view of encrypted files as if the cryptographic metadata were
stored in the file header, whether the metadata is actually stored
in the header or in the extended attributes.
No matter what eCryptfs winds up doing in the lower filesystem, I want
to preserve a baseline format compatibility for the encrypted files. As of
right now, the metadata may be in the file header or in an xattr. There is
no reason why the metadata could not be put in a separate file in future
versions.
Without the compatibility mode, backup utilities would have to know to
back up the metadata file along with the files. The semantics of eCryptfs
have always been that the lower files are self-contained units of encrypted
data, and the only additional information required to decrypt any given
eCryptfs file is the key. That is what has always been emphasized about
eCryptfs lower files, and that is what users expect. Providing the
encrypted view option will provide a way to userspace applications wherein
they can always get to the same old familiar eCryptfs encrypted files,
regardless of what eCryptfs winds up doing with the metadata behind the
scenes.
This patch:
Add extended attribute support to version bit vector, flags to indicate when
xattr or encrypted view modes are enabled, and support for the new mount
options.
Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-12 08:53:45 +00:00
|
|
|
#define ECRYPTFS_VERSIONING_PASSPHRASE 0x00000001
|
|
|
|
|
#define ECRYPTFS_VERSIONING_PUBKEY 0x00000002
|
2006-10-04 09:16:22 +00:00
|
|
|
#define ECRYPTFS_VERSIONING_PLAINTEXT_PASSTHROUGH 0x00000004
|
[PATCH] eCryptfs: xattr flags and mount options
This patch set introduces the ability to store cryptographic metadata into an
lower file extended attribute rather than the lower file header region.
This patch set implements two new mount options:
ecryptfs_xattr_metadata
- When set, newly created files will have their cryptographic
metadata stored in the extended attribute region of the file rather
than the header.
When storing the data in the file header, there is a minimum of 8KB
reserved for the header information for each file, making each file at
least 12KB in size. This can take up a lot of extra disk space if the user
creates a lot of small files. By storing the data in the extended
attribute, each file will only occupy at least of 4KB of space.
As the eCryptfs metadata set becomes larger with new features such as
multi-key associations, most popular filesystems will not be able to store
all of the information in the xattr region in some cases due to space
constraints. However, the majority of users will only ever associate one
key per file, so most users will be okay with storing their data in the
xattr region.
This option should be used with caution. I want to emphasize that the
xattr must be maintained under all circumstances, or the file will be
rendered permanently unrecoverable. The last thing I want is for a user to
forget to set an xattr flag in a backup utility, only to later discover
that their backups are worthless.
ecryptfs_encrypted_view
- When set, this option causes eCryptfs to present applications a
view of encrypted files as if the cryptographic metadata were
stored in the file header, whether the metadata is actually stored
in the header or in the extended attributes.
No matter what eCryptfs winds up doing in the lower filesystem, I want
to preserve a baseline format compatibility for the encrypted files. As of
right now, the metadata may be in the file header or in an xattr. There is
no reason why the metadata could not be put in a separate file in future
versions.
Without the compatibility mode, backup utilities would have to know to
back up the metadata file along with the files. The semantics of eCryptfs
have always been that the lower files are self-contained units of encrypted
data, and the only additional information required to decrypt any given
eCryptfs file is the key. That is what has always been emphasized about
eCryptfs lower files, and that is what users expect. Providing the
encrypted view option will provide a way to userspace applications wherein
they can always get to the same old familiar eCryptfs encrypted files,
regardless of what eCryptfs winds up doing with the metadata behind the
scenes.
This patch:
Add extended attribute support to version bit vector, flags to indicate when
xattr or encrypted view modes are enabled, and support for the new mount
options.
Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-12 08:53:45 +00:00
|
|
|
#define ECRYPTFS_VERSIONING_POLICY 0x00000008
|
|
|
|
|
#define ECRYPTFS_VERSIONING_XATTR 0x00000010
|
2006-10-04 09:16:22 +00:00
|
|
|
#define ECRYPTFS_VERSIONING_MASK (ECRYPTFS_VERSIONING_PASSPHRASE \
|
[PATCH] eCryptfs: xattr flags and mount options
This patch set introduces the ability to store cryptographic metadata into an
lower file extended attribute rather than the lower file header region.
This patch set implements two new mount options:
ecryptfs_xattr_metadata
- When set, newly created files will have their cryptographic
metadata stored in the extended attribute region of the file rather
than the header.
When storing the data in the file header, there is a minimum of 8KB
reserved for the header information for each file, making each file at
least 12KB in size. This can take up a lot of extra disk space if the user
creates a lot of small files. By storing the data in the extended
attribute, each file will only occupy at least of 4KB of space.
As the eCryptfs metadata set becomes larger with new features such as
multi-key associations, most popular filesystems will not be able to store
all of the information in the xattr region in some cases due to space
constraints. However, the majority of users will only ever associate one
key per file, so most users will be okay with storing their data in the
xattr region.
This option should be used with caution. I want to emphasize that the
xattr must be maintained under all circumstances, or the file will be
rendered permanently unrecoverable. The last thing I want is for a user to
forget to set an xattr flag in a backup utility, only to later discover
that their backups are worthless.
ecryptfs_encrypted_view
- When set, this option causes eCryptfs to present applications a
view of encrypted files as if the cryptographic metadata were
stored in the file header, whether the metadata is actually stored
in the header or in the extended attributes.
No matter what eCryptfs winds up doing in the lower filesystem, I want
to preserve a baseline format compatibility for the encrypted files. As of
right now, the metadata may be in the file header or in an xattr. There is
no reason why the metadata could not be put in a separate file in future
versions.
Without the compatibility mode, backup utilities would have to know to
back up the metadata file along with the files. The semantics of eCryptfs
have always been that the lower files are self-contained units of encrypted
data, and the only additional information required to decrypt any given
eCryptfs file is the key. That is what has always been emphasized about
eCryptfs lower files, and that is what users expect. Providing the
encrypted view option will provide a way to userspace applications wherein
they can always get to the same old familiar eCryptfs encrypted files,
regardless of what eCryptfs winds up doing with the metadata behind the
scenes.
This patch:
Add extended attribute support to version bit vector, flags to indicate when
xattr or encrypted view modes are enabled, and support for the new mount
options.
Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-12 08:53:45 +00:00
|
|
|
| ECRYPTFS_VERSIONING_PLAINTEXT_PASSTHROUGH \
|
2007-02-12 08:53:46 +00:00
|
|
|
| ECRYPTFS_VERSIONING_PUBKEY \
|
|
|
|
|
| ECRYPTFS_VERSIONING_XATTR)
|
2006-10-04 09:16:22 +00:00
|
|
|
#define ECRYPTFS_MAX_PASSWORD_LENGTH 64
|
|
|
|
|
#define ECRYPTFS_MAX_PASSPHRASE_BYTES ECRYPTFS_MAX_PASSWORD_LENGTH
|
|
|
|
|
#define ECRYPTFS_SALT_SIZE 8
|
|
|
|
|
#define ECRYPTFS_SALT_SIZE_HEX (ECRYPTFS_SALT_SIZE*2)
|
|
|
|
|
/* The original signature size is only for what is stored on disk; all
|
|
|
|
|
* in-memory representations are expanded hex, so it better adapted to
|
|
|
|
|
* be passed around or referenced on the command line */
|
|
|
|
|
#define ECRYPTFS_SIG_SIZE 8
|
|
|
|
|
#define ECRYPTFS_SIG_SIZE_HEX (ECRYPTFS_SIG_SIZE*2)
|
|
|
|
|
#define ECRYPTFS_PASSWORD_SIG_SIZE ECRYPTFS_SIG_SIZE_HEX
|
|
|
|
|
#define ECRYPTFS_MAX_KEY_BYTES 64
|
|
|
|
|
#define ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES 512
|
|
|
|
|
#define ECRYPTFS_DEFAULT_IV_BYTES 16
|
[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>
2007-02-12 08:53:43 +00:00
|
|
|
#define ECRYPTFS_FILE_VERSION 0x02
|
2006-10-04 09:16:22 +00:00
|
|
|
#define ECRYPTFS_DEFAULT_HEADER_EXTENT_SIZE 8192
|
|
|
|
|
#define ECRYPTFS_DEFAULT_EXTENT_SIZE 4096
|
|
|
|
|
#define ECRYPTFS_MINIMUM_HEADER_EXTENT_SIZE 8192
|
[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>
2007-02-12 08:53:43 +00:00
|
|
|
#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
|
2007-02-12 08:53:46 +00:00
|
|
|
#define ECRYPTFS_XATTR_NAME "user.ecryptfs"
|
2006-10-04 09:16:22 +00:00
|
|
|
|
|
|
|
|
#define RFC2440_CIPHER_DES3_EDE 0x02
|
|
|
|
|
#define RFC2440_CIPHER_CAST_5 0x03
|
|
|
|
|
#define RFC2440_CIPHER_BLOWFISH 0x04
|
|
|
|
|
#define RFC2440_CIPHER_AES_128 0x07
|
|
|
|
|
#define RFC2440_CIPHER_AES_192 0x08
|
|
|
|
|
#define RFC2440_CIPHER_AES_256 0x09
|
|
|
|
|
#define RFC2440_CIPHER_TWOFISH 0x0a
|
|
|
|
|
#define RFC2440_CIPHER_CAST_6 0x0b
|
|
|
|
|
|
[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>
2007-02-12 08:53:43 +00:00
|
|
|
#define RFC2440_CIPHER_RSA 0x01
|
2006-10-04 09:16:22 +00:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* For convenience, we may need to pass around the encrypted session
|
|
|
|
|
* key between kernel and userspace because the authentication token
|
|
|
|
|
* may not be extractable. For example, the TPM may not release the
|
|
|
|
|
* private key, instead requiring the encrypted data and returning the
|
|
|
|
|
* decrypted data.
|
|
|
|
|
*/
|
|
|
|
|
struct ecryptfs_session_key {
|
|
|
|
|
#define ECRYPTFS_USERSPACE_SHOULD_TRY_TO_DECRYPT 0x00000001
|
|
|
|
|
#define ECRYPTFS_USERSPACE_SHOULD_TRY_TO_ENCRYPT 0x00000002
|
|
|
|
|
#define ECRYPTFS_CONTAINS_DECRYPTED_KEY 0x00000004
|
|
|
|
|
#define ECRYPTFS_CONTAINS_ENCRYPTED_KEY 0x00000008
|
|
|
|
|
u32 flags;
|
|
|
|
|
u32 encrypted_key_size;
|
|
|
|
|
u32 decrypted_key_size;
|
|
|
|
|
u8 encrypted_key[ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES];
|
|
|
|
|
u8 decrypted_key[ECRYPTFS_MAX_KEY_BYTES];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ecryptfs_password {
|
|
|
|
|
u32 password_bytes;
|
|
|
|
|
s32 hash_algo;
|
|
|
|
|
u32 hash_iterations;
|
|
|
|
|
u32 session_key_encryption_key_bytes;
|
|
|
|
|
#define ECRYPTFS_PERSISTENT_PASSWORD 0x01
|
|
|
|
|
#define ECRYPTFS_SESSION_KEY_ENCRYPTION_KEY_SET 0x02
|
|
|
|
|
u32 flags;
|
|
|
|
|
/* Iterated-hash concatenation of salt and passphrase */
|
|
|
|
|
u8 session_key_encryption_key[ECRYPTFS_MAX_KEY_BYTES];
|
|
|
|
|
u8 signature[ECRYPTFS_PASSWORD_SIG_SIZE + 1];
|
|
|
|
|
/* Always in expanded hex */
|
|
|
|
|
u8 salt[ECRYPTFS_SALT_SIZE];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
enum ecryptfs_token_types {ECRYPTFS_PASSWORD, ECRYPTFS_PRIVATE_KEY};
|
|
|
|
|
|
[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>
2007-02-12 08:53:43 +00:00
|
|
|
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[];
|
|
|
|
|
};
|
|
|
|
|
|
2006-10-04 09:16:22 +00:00
|
|
|
/* May be a password or a private key */
|
|
|
|
|
struct ecryptfs_auth_tok {
|
|
|
|
|
u16 version; /* 8-bit major and 8-bit minor */
|
|
|
|
|
u16 token_type;
|
|
|
|
|
u32 flags;
|
|
|
|
|
struct ecryptfs_session_key session_key;
|
|
|
|
|
u8 reserved[32];
|
|
|
|
|
union {
|
|
|
|
|
struct ecryptfs_password password;
|
[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>
2007-02-12 08:53:43 +00:00
|
|
|
struct ecryptfs_private_key private_key;
|
2006-10-04 09:16:22 +00:00
|
|
|
} token;
|
|
|
|
|
} __attribute__ ((packed));
|
|
|
|
|
|
|
|
|
|
void ecryptfs_dump_auth_tok(struct ecryptfs_auth_tok *auth_tok);
|
|
|
|
|
extern void ecryptfs_to_hex(char *dst, char *src, size_t src_size);
|
|
|
|
|
extern void ecryptfs_from_hex(char *dst, char *src, int dst_size);
|
|
|
|
|
|
|
|
|
|
struct ecryptfs_key_record {
|
|
|
|
|
unsigned char type;
|
|
|
|
|
size_t enc_key_size;
|
|
|
|
|
unsigned char sig[ECRYPTFS_SIG_SIZE];
|
|
|
|
|
unsigned char enc_key[ECRYPTFS_MAX_ENCRYPTED_KEY_BYTES];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ecryptfs_auth_tok_list {
|
|
|
|
|
struct ecryptfs_auth_tok *auth_tok;
|
|
|
|
|
struct list_head list;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct ecryptfs_crypt_stat;
|
|
|
|
|
struct ecryptfs_mount_crypt_stat;
|
|
|
|
|
|
|
|
|
|
struct ecryptfs_page_crypt_context {
|
|
|
|
|
struct page *page;
|
|
|
|
|
#define ECRYPTFS_PREPARE_COMMIT_MODE 0
|
|
|
|
|
#define ECRYPTFS_WRITEPAGE_MODE 1
|
|
|
|
|
unsigned int mode;
|
|
|
|
|
union {
|
|
|
|
|
struct file *lower_file;
|
|
|
|
|
struct writeback_control *wbc;
|
|
|
|
|
} param;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static inline struct ecryptfs_auth_tok *
|
|
|
|
|
ecryptfs_get_key_payload_data(struct key *key)
|
|
|
|
|
{
|
|
|
|
|
return (struct ecryptfs_auth_tok *)
|
|
|
|
|
(((struct user_key_payload*)key->payload.data)->data);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#define ECRYPTFS_SUPER_MAGIC 0xf15f
|
|
|
|
|
#define ECRYPTFS_MAX_KEYSET_SIZE 1024
|
|
|
|
|
#define ECRYPTFS_MAX_CIPHER_NAME_SIZE 32
|
|
|
|
|
#define ECRYPTFS_MAX_NUM_ENC_KEYS 64
|
|
|
|
|
#define ECRYPTFS_MAX_NUM_KEYSIGS 2 /* TODO: Make this a linked list */
|
|
|
|
|
#define ECRYPTFS_MAX_IV_BYTES 16 /* 128 bits */
|
|
|
|
|
#define ECRYPTFS_SALT_BYTES 2
|
|
|
|
|
#define MAGIC_ECRYPTFS_MARKER 0x3c81b7f5
|
|
|
|
|
#define MAGIC_ECRYPTFS_MARKER_SIZE_BYTES 8 /* 4*2 */
|
|
|
|
|
#define ECRYPTFS_FILE_SIZE_BYTES 8
|
|
|
|
|
#define ECRYPTFS_DEFAULT_CIPHER "aes"
|
|
|
|
|
#define ECRYPTFS_DEFAULT_KEY_BYTES 16
|
2006-10-31 06:07:17 +00:00
|
|
|
#define ECRYPTFS_DEFAULT_HASH "md5"
|
[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>
2007-02-12 08:53:43 +00:00
|
|
|
#define ECRYPTFS_TAG_1_PACKET_TYPE 0x01
|
2006-10-04 09:16:22 +00:00
|
|
|
#define ECRYPTFS_TAG_3_PACKET_TYPE 0x8C
|
|
|
|
|
#define ECRYPTFS_TAG_11_PACKET_TYPE 0xED
|
[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>
2007-02-12 08:53:43 +00:00
|
|
|
#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
|
2006-10-04 09:16:22 +00:00
|
|
|
#define MD5_DIGEST_SIZE 16
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* This is the primary struct associated with each encrypted file.
|
|
|
|
|
*
|
|
|
|
|
* TODO: cache align/pack?
|
|
|
|
|
*/
|
|
|
|
|
struct ecryptfs_crypt_stat {
|
|
|
|
|
#define ECRYPTFS_STRUCT_INITIALIZED 0x00000001
|
|
|
|
|
#define ECRYPTFS_POLICY_APPLIED 0x00000002
|
|
|
|
|
#define ECRYPTFS_NEW_FILE 0x00000004
|
|
|
|
|
#define ECRYPTFS_ENCRYPTED 0x00000008
|
|
|
|
|
#define ECRYPTFS_SECURITY_WARNING 0x00000010
|
|
|
|
|
#define ECRYPTFS_ENABLE_HMAC 0x00000020
|
|
|
|
|
#define ECRYPTFS_ENCRYPT_IV_PAGES 0x00000040
|
|
|
|
|
#define ECRYPTFS_KEY_VALID 0x00000080
|
[PATCH] eCryptfs: xattr flags and mount options
This patch set introduces the ability to store cryptographic metadata into an
lower file extended attribute rather than the lower file header region.
This patch set implements two new mount options:
ecryptfs_xattr_metadata
- When set, newly created files will have their cryptographic
metadata stored in the extended attribute region of the file rather
than the header.
When storing the data in the file header, there is a minimum of 8KB
reserved for the header information for each file, making each file at
least 12KB in size. This can take up a lot of extra disk space if the user
creates a lot of small files. By storing the data in the extended
attribute, each file will only occupy at least of 4KB of space.
As the eCryptfs metadata set becomes larger with new features such as
multi-key associations, most popular filesystems will not be able to store
all of the information in the xattr region in some cases due to space
constraints. However, the majority of users will only ever associate one
key per file, so most users will be okay with storing their data in the
xattr region.
This option should be used with caution. I want to emphasize that the
xattr must be maintained under all circumstances, or the file will be
rendered permanently unrecoverable. The last thing I want is for a user to
forget to set an xattr flag in a backup utility, only to later discover
that their backups are worthless.
ecryptfs_encrypted_view
- When set, this option causes eCryptfs to present applications a
view of encrypted files as if the cryptographic metadata were
stored in the file header, whether the metadata is actually stored
in the header or in the extended attributes.
No matter what eCryptfs winds up doing in the lower filesystem, I want
to preserve a baseline format compatibility for the encrypted files. As of
right now, the metadata may be in the file header or in an xattr. There is
no reason why the metadata could not be put in a separate file in future
versions.
Without the compatibility mode, backup utilities would have to know to
back up the metadata file along with the files. The semantics of eCryptfs
have always been that the lower files are self-contained units of encrypted
data, and the only additional information required to decrypt any given
eCryptfs file is the key. That is what has always been emphasized about
eCryptfs lower files, and that is what users expect. Providing the
encrypted view option will provide a way to userspace applications wherein
they can always get to the same old familiar eCryptfs encrypted files,
regardless of what eCryptfs winds up doing with the metadata behind the
scenes.
This patch:
Add extended attribute support to version bit vector, flags to indicate when
xattr or encrypted view modes are enabled, and support for the new mount
options.
Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-12 08:53:45 +00:00
|
|
|
#define ECRYPTFS_METADATA_IN_XATTR 0x00000100
|
|
|
|
|
#define ECRYPTFS_VIEW_AS_ENCRYPTED 0x00000200
|
2006-10-04 09:16:22 +00:00
|
|
|
u32 flags;
|
|
|
|
|
unsigned int file_version;
|
|
|
|
|
size_t iv_bytes;
|
|
|
|
|
size_t num_keysigs;
|
|
|
|
|
size_t header_extent_size;
|
|
|
|
|
size_t num_header_extents_at_front;
|
|
|
|
|
size_t extent_size; /* Data extent size; default is 4096 */
|
|
|
|
|
size_t key_size;
|
|
|
|
|
size_t extent_shift;
|
|
|
|
|
unsigned int extent_mask;
|
|
|
|
|
struct ecryptfs_mount_crypt_stat *mount_crypt_stat;
|
2006-10-31 06:07:18 +00:00
|
|
|
struct crypto_blkcipher *tfm;
|
2006-10-31 06:07:17 +00:00
|
|
|
struct crypto_hash *hash_tfm; /* Crypto context for generating
|
|
|
|
|
* the initialization vectors */
|
2006-10-04 09:16:22 +00:00
|
|
|
unsigned char cipher[ECRYPTFS_MAX_CIPHER_NAME_SIZE];
|
|
|
|
|
unsigned char key[ECRYPTFS_MAX_KEY_BYTES];
|
|
|
|
|
unsigned char root_iv[ECRYPTFS_MAX_IV_BYTES];
|
|
|
|
|
unsigned char keysigs[ECRYPTFS_MAX_NUM_KEYSIGS][ECRYPTFS_SIG_SIZE_HEX];
|
|
|
|
|
struct mutex cs_tfm_mutex;
|
2006-10-31 06:07:17 +00:00
|
|
|
struct mutex cs_hash_tfm_mutex;
|
2006-10-04 09:16:22 +00:00
|
|
|
struct mutex cs_mutex;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* inode private data. */
|
|
|
|
|
struct ecryptfs_inode_info {
|
|
|
|
|
struct inode vfs_inode;
|
|
|
|
|
struct inode *wii_inode;
|
|
|
|
|
struct ecryptfs_crypt_stat crypt_stat;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* dentry private data. Each dentry must keep track of a lower
|
|
|
|
|
* vfsmount too. */
|
|
|
|
|
struct ecryptfs_dentry_info {
|
2006-12-08 10:36:34 +00:00
|
|
|
struct path lower_path;
|
2006-10-04 09:16:22 +00:00
|
|
|
struct ecryptfs_crypt_stat *crypt_stat;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* This struct is to enable a mount-wide passphrase/salt combo. This
|
|
|
|
|
* is more or less a stopgap to provide similar functionality to other
|
|
|
|
|
* crypto filesystems like EncFS or CFS until full policy support is
|
|
|
|
|
* implemented in eCryptfs.
|
|
|
|
|
*/
|
|
|
|
|
struct ecryptfs_mount_crypt_stat {
|
|
|
|
|
/* Pointers to memory we do not own, do not free these */
|
|
|
|
|
#define ECRYPTFS_PLAINTEXT_PASSTHROUGH_ENABLED 0x00000001
|
[PATCH] eCryptfs: xattr flags and mount options
This patch set introduces the ability to store cryptographic metadata into an
lower file extended attribute rather than the lower file header region.
This patch set implements two new mount options:
ecryptfs_xattr_metadata
- When set, newly created files will have their cryptographic
metadata stored in the extended attribute region of the file rather
than the header.
When storing the data in the file header, there is a minimum of 8KB
reserved for the header information for each file, making each file at
least 12KB in size. This can take up a lot of extra disk space if the user
creates a lot of small files. By storing the data in the extended
attribute, each file will only occupy at least of 4KB of space.
As the eCryptfs metadata set becomes larger with new features such as
multi-key associations, most popular filesystems will not be able to store
all of the information in the xattr region in some cases due to space
constraints. However, the majority of users will only ever associate one
key per file, so most users will be okay with storing their data in the
xattr region.
This option should be used with caution. I want to emphasize that the
xattr must be maintained under all circumstances, or the file will be
rendered permanently unrecoverable. The last thing I want is for a user to
forget to set an xattr flag in a backup utility, only to later discover
that their backups are worthless.
ecryptfs_encrypted_view
- When set, this option causes eCryptfs to present applications a
view of encrypted files as if the cryptographic metadata were
stored in the file header, whether the metadata is actually stored
in the header or in the extended attributes.
No matter what eCryptfs winds up doing in the lower filesystem, I want
to preserve a baseline format compatibility for the encrypted files. As of
right now, the metadata may be in the file header or in an xattr. There is
no reason why the metadata could not be put in a separate file in future
versions.
Without the compatibility mode, backup utilities would have to know to
back up the metadata file along with the files. The semantics of eCryptfs
have always been that the lower files are self-contained units of encrypted
data, and the only additional information required to decrypt any given
eCryptfs file is the key. That is what has always been emphasized about
eCryptfs lower files, and that is what users expect. Providing the
encrypted view option will provide a way to userspace applications wherein
they can always get to the same old familiar eCryptfs encrypted files,
regardless of what eCryptfs winds up doing with the metadata behind the
scenes.
This patch:
Add extended attribute support to version bit vector, flags to indicate when
xattr or encrypted view modes are enabled, and support for the new mount
options.
Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-02-12 08:53:45 +00:00
|
|
|
#define ECRYPTFS_XATTR_METADATA_ENABLED 0x00000002
|
|
|
|
|
#define ECRYPTFS_ENCRYPTED_VIEW_ENABLED 0x00000004
|
2006-10-04 09:16:22 +00:00
|
|
|
u32 flags;
|
|
|
|
|
struct ecryptfs_auth_tok *global_auth_tok;
|
|
|
|
|
struct key *global_auth_tok_key;
|
|
|
|
|
size_t global_default_cipher_key_size;
|
2006-10-31 06:07:18 +00:00
|
|
|
struct crypto_blkcipher *global_key_tfm;
|
2006-10-04 09:16:22 +00:00
|
|
|
struct mutex global_key_tfm_mutex;
|
|
|
|
|
unsigned char global_default_cipher_name[ECRYPTFS_MAX_CIPHER_NAME_SIZE
|
|
|
|
|
+ 1];
|
|
|
|
|
unsigned char global_auth_tok_sig[ECRYPTFS_SIG_SIZE_HEX + 1];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* superblock private data. */
|
|
|
|
|
struct ecryptfs_sb_info {
|
|
|
|
|
struct super_block *wsi_sb;
|
|
|
|
|
struct ecryptfs_mount_crypt_stat mount_crypt_stat;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* file private data. */
|
|
|
|
|
struct ecryptfs_file_info {
|
|
|
|
|
struct file *wfi_file;
|
|
|
|
|
struct ecryptfs_crypt_stat *crypt_stat;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/* auth_tok <=> encrypted_session_key mappings */
|
|
|
|
|
struct ecryptfs_auth_tok_list_item {
|
|
|
|
|
unsigned char encrypted_session_key[ECRYPTFS_MAX_KEY_BYTES];
|
|
|
|
|
struct list_head list;
|
|
|
|
|
struct ecryptfs_auth_tok auth_tok;
|
|
|
|
|
};
|
|
|
|
|
|
[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>
2007-02-12 08:53:43 +00:00
|
|
|
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;
|
|
|
|
|
unsigned int index;
|
|
|
|
|
unsigned int counter;
|
|
|
|
|
struct ecryptfs_message *msg;
|
|
|
|
|
struct task_struct *task;
|
|
|
|
|
struct list_head node;
|
|
|
|
|
struct mutex mux;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
extern unsigned int ecryptfs_transport;
|
|
|
|
|
|
|
|
|
|
struct ecryptfs_daemon_id {
|
|
|
|
|
pid_t pid;
|
|
|
|
|
uid_t uid;
|
|
|
|
|
struct hlist_node id_chain;
|
|
|
|
|
};
|
|
|
|
|
|
2006-10-04 09:16:22 +00:00
|
|
|
static inline struct ecryptfs_file_info *
|
|
|
|
|
ecryptfs_file_to_private(struct file *file)
|
|
|
|
|
{
|
|
|
|
|
return (struct ecryptfs_file_info *)file->private_data;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
|
ecryptfs_set_file_private(struct file *file,
|
|
|
|
|
struct ecryptfs_file_info *file_info)
|
|
|
|
|
{
|
|
|
|
|
file->private_data = file_info;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct file *ecryptfs_file_to_lower(struct file *file)
|
|
|
|
|
{
|
|
|
|
|
return ((struct ecryptfs_file_info *)file->private_data)->wfi_file;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
|
ecryptfs_set_file_lower(struct file *file, struct file *lower_file)
|
|
|
|
|
{
|
|
|
|
|
((struct ecryptfs_file_info *)file->private_data)->wfi_file =
|
|
|
|
|
lower_file;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct ecryptfs_inode_info *
|
|
|
|
|
ecryptfs_inode_to_private(struct inode *inode)
|
|
|
|
|
{
|
|
|
|
|
return container_of(inode, struct ecryptfs_inode_info, vfs_inode);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct inode *ecryptfs_inode_to_lower(struct inode *inode)
|
|
|
|
|
{
|
|
|
|
|
return ecryptfs_inode_to_private(inode)->wii_inode;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
|
ecryptfs_set_inode_lower(struct inode *inode, struct inode *lower_inode)
|
|
|
|
|
{
|
|
|
|
|
ecryptfs_inode_to_private(inode)->wii_inode = lower_inode;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct ecryptfs_sb_info *
|
|
|
|
|
ecryptfs_superblock_to_private(struct super_block *sb)
|
|
|
|
|
{
|
|
|
|
|
return (struct ecryptfs_sb_info *)sb->s_fs_info;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
|
ecryptfs_set_superblock_private(struct super_block *sb,
|
|
|
|
|
struct ecryptfs_sb_info *sb_info)
|
|
|
|
|
{
|
|
|
|
|
sb->s_fs_info = sb_info;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct super_block *
|
|
|
|
|
ecryptfs_superblock_to_lower(struct super_block *sb)
|
|
|
|
|
{
|
|
|
|
|
return ((struct ecryptfs_sb_info *)sb->s_fs_info)->wsi_sb;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
|
ecryptfs_set_superblock_lower(struct super_block *sb,
|
|
|
|
|
struct super_block *lower_sb)
|
|
|
|
|
{
|
|
|
|
|
((struct ecryptfs_sb_info *)sb->s_fs_info)->wsi_sb = lower_sb;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct ecryptfs_dentry_info *
|
|
|
|
|
ecryptfs_dentry_to_private(struct dentry *dentry)
|
|
|
|
|
{
|
|
|
|
|
return (struct ecryptfs_dentry_info *)dentry->d_fsdata;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
|
ecryptfs_set_dentry_private(struct dentry *dentry,
|
|
|
|
|
struct ecryptfs_dentry_info *dentry_info)
|
|
|
|
|
{
|
|
|
|
|
dentry->d_fsdata = dentry_info;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct dentry *
|
|
|
|
|
ecryptfs_dentry_to_lower(struct dentry *dentry)
|
|
|
|
|
{
|
2006-12-08 10:36:34 +00:00
|
|
|
return ((struct ecryptfs_dentry_info *)dentry->d_fsdata)->lower_path.dentry;
|
2006-10-04 09:16:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
|
ecryptfs_set_dentry_lower(struct dentry *dentry, struct dentry *lower_dentry)
|
|
|
|
|
{
|
2006-12-08 10:36:34 +00:00
|
|
|
((struct ecryptfs_dentry_info *)dentry->d_fsdata)->lower_path.dentry =
|
2006-10-04 09:16:22 +00:00
|
|
|
lower_dentry;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline struct vfsmount *
|
|
|
|
|
ecryptfs_dentry_to_lower_mnt(struct dentry *dentry)
|
|
|
|
|
{
|
2006-12-08 10:36:34 +00:00
|
|
|
return ((struct ecryptfs_dentry_info *)dentry->d_fsdata)->lower_path.mnt;
|
2006-10-04 09:16:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
|
ecryptfs_set_dentry_lower_mnt(struct dentry *dentry, struct vfsmount *lower_mnt)
|
|
|
|
|
{
|
2006-12-08 10:36:34 +00:00
|
|
|
((struct ecryptfs_dentry_info *)dentry->d_fsdata)->lower_path.mnt =
|
2006-10-04 09:16:22 +00:00
|
|
|
lower_mnt;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#define ecryptfs_printk(type, fmt, arg...) \
|
|
|
|
|
__ecryptfs_printk(type "%s: " fmt, __FUNCTION__, ## arg);
|
|
|
|
|
void __ecryptfs_printk(const char *fmt, ...);
|
|
|
|
|
|
|
|
|
|
extern const struct file_operations ecryptfs_main_fops;
|
|
|
|
|
extern const struct file_operations ecryptfs_dir_fops;
|
2007-02-12 08:55:38 +00:00
|
|
|
extern const struct inode_operations ecryptfs_main_iops;
|
|
|
|
|
extern const struct inode_operations ecryptfs_dir_iops;
|
|
|
|
|
extern const struct inode_operations ecryptfs_symlink_iops;
|
2007-02-12 08:55:41 +00:00
|
|
|
extern const struct super_operations ecryptfs_sops;
|
2006-10-04 09:16:22 +00:00
|
|
|
extern struct dentry_operations ecryptfs_dops;
|
|
|
|
|
extern struct address_space_operations ecryptfs_aops;
|
|
|
|
|
extern int ecryptfs_verbosity;
|
[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>
2007-02-12 08:53:43 +00:00
|
|
|
extern unsigned int ecryptfs_message_buf_len;
|
|
|
|
|
extern signed long ecryptfs_message_wait_timeout;
|
|
|
|
|
extern unsigned int ecryptfs_number_of_users;
|
2006-10-04 09:16:22 +00:00
|
|
|
|
|
|
|
|
extern struct kmem_cache *ecryptfs_auth_tok_list_item_cache;
|
|
|
|
|
extern struct kmem_cache *ecryptfs_file_info_cache;
|
|
|
|
|
extern struct kmem_cache *ecryptfs_dentry_info_cache;
|
|
|
|
|
extern struct kmem_cache *ecryptfs_inode_info_cache;
|
|
|
|
|
extern struct kmem_cache *ecryptfs_sb_info_cache;
|
|
|
|
|
extern struct kmem_cache *ecryptfs_header_cache_0;
|
|
|
|
|
extern struct kmem_cache *ecryptfs_header_cache_1;
|
|
|
|
|
extern struct kmem_cache *ecryptfs_header_cache_2;
|
2007-02-12 08:53:46 +00:00
|
|
|
extern struct kmem_cache *ecryptfs_xattr_cache;
|
2006-10-04 09:16:22 +00:00
|
|
|
extern struct kmem_cache *ecryptfs_lower_page_cache;
|
2007-02-16 09:28:40 +00:00
|
|
|
extern struct kmem_cache *ecryptfs_key_record_cache;
|
2006-10-04 09:16:22 +00:00
|
|
|
|
|
|
|
|
int ecryptfs_interpose(struct dentry *hidden_dentry,
|
|
|
|
|
struct dentry *this_dentry, struct super_block *sb,
|
|
|
|
|
int flag);
|
|
|
|
|
int ecryptfs_fill_zeros(struct file *file, loff_t new_length);
|
|
|
|
|
int ecryptfs_decode_filename(struct ecryptfs_crypt_stat *crypt_stat,
|
|
|
|
|
const char *name, int length,
|
|
|
|
|
char **decrypted_name);
|
|
|
|
|
int ecryptfs_encode_filename(struct ecryptfs_crypt_stat *crypt_stat,
|
|
|
|
|
const char *name, int length,
|
|
|
|
|
char **encoded_name);
|
|
|
|
|
struct dentry *ecryptfs_lower_dentry(struct dentry *this_dentry);
|
|
|
|
|
void ecryptfs_dump_hex(char *data, int bytes);
|
|
|
|
|
int virt_to_scatterlist(const void *addr, int size, struct scatterlist *sg,
|
|
|
|
|
int sg_size);
|
|
|
|
|
int ecryptfs_compute_root_iv(struct ecryptfs_crypt_stat *crypt_stat);
|
|
|
|
|
void ecryptfs_rotate_iv(unsigned char *iv);
|
|
|
|
|
void ecryptfs_init_crypt_stat(struct ecryptfs_crypt_stat *crypt_stat);
|
|
|
|
|
void ecryptfs_destruct_crypt_stat(struct ecryptfs_crypt_stat *crypt_stat);
|
|
|
|
|
void ecryptfs_destruct_mount_crypt_stat(
|
|
|
|
|
struct ecryptfs_mount_crypt_stat *mount_crypt_stat);
|
|
|
|
|
int ecryptfs_init_crypt_ctx(struct ecryptfs_crypt_stat *crypt_stat);
|
2006-10-31 06:07:18 +00:00
|
|
|
int ecryptfs_crypto_api_algify_cipher_name(char **algified_name,
|
|
|
|
|
char *cipher_name,
|
|
|
|
|
char *chaining_modifier);
|
2007-02-12 08:53:46 +00:00
|
|
|
#define ECRYPTFS_LOWER_I_MUTEX_NOT_HELD 0
|
|
|
|
|
#define ECRYPTFS_LOWER_I_MUTEX_HELD 1
|
|
|
|
|
int ecryptfs_write_inode_size_to_metadata(struct file *lower_file,
|
|
|
|
|
struct inode *lower_inode,
|
|
|
|
|
struct inode *inode,
|
|
|
|
|
struct dentry *ecryptfs_dentry,
|
|
|
|
|
int lower_i_mutex_held);
|
2006-10-04 09:16:22 +00:00
|
|
|
int ecryptfs_get_lower_page(struct page **lower_page, struct inode *lower_inode,
|
|
|
|
|
struct file *lower_file,
|
|
|
|
|
unsigned long lower_page_index, int byte_offset,
|
|
|
|
|
int region_bytes);
|
|
|
|
|
int
|
|
|
|
|
ecryptfs_commit_lower_page(struct page *lower_page, struct inode *lower_inode,
|
|
|
|
|
struct file *lower_file, int byte_offset,
|
|
|
|
|
int region_size);
|
|
|
|
|
int ecryptfs_copy_page_to_lower(struct page *page, struct inode *lower_inode,
|
|
|
|
|
struct file *lower_file);
|
|
|
|
|
int ecryptfs_do_readpage(struct file *file, struct page *page,
|
|
|
|
|
pgoff_t lower_page_index);
|
|
|
|
|
int ecryptfs_writepage_and_release_lower_page(struct page *lower_page,
|
|
|
|
|
struct inode *lower_inode,
|
|
|
|
|
struct writeback_control *wbc);
|
|
|
|
|
int ecryptfs_encrypt_page(struct ecryptfs_page_crypt_context *ctx);
|
|
|
|
|
int ecryptfs_decrypt_page(struct file *file, struct page *page);
|
2007-02-12 08:53:46 +00:00
|
|
|
int ecryptfs_write_metadata(struct dentry *ecryptfs_dentry,
|
|
|
|
|
struct file *lower_file);
|
|
|
|
|
int ecryptfs_read_metadata(struct dentry *ecryptfs_dentry,
|
2006-10-04 09:16:22 +00:00
|
|
|
struct file *lower_file);
|
|
|
|
|
int ecryptfs_new_file_context(struct dentry *ecryptfs_dentry);
|
2007-02-12 08:53:46 +00:00
|
|
|
int ecryptfs_read_and_validate_header_region(char *data, struct dentry *dentry,
|
|
|
|
|
struct vfsmount *mnt);
|
|
|
|
|
int ecryptfs_read_and_validate_xattr_region(char *page_virt,
|
|
|
|
|
struct dentry *ecryptfs_dentry);
|
2006-10-04 09:16:22 +00:00
|
|
|
u16 ecryptfs_code_for_cipher_string(struct ecryptfs_crypt_stat *crypt_stat);
|
|
|
|
|
int ecryptfs_cipher_code_to_string(char *str, u16 cipher_code);
|
|
|
|
|
void ecryptfs_set_default_sizes(struct ecryptfs_crypt_stat *crypt_stat);
|
|
|
|
|
int ecryptfs_generate_key_packet_set(char *dest_base,
|
|
|
|
|
struct ecryptfs_crypt_stat *crypt_stat,
|
|
|
|
|
struct dentry *ecryptfs_dentry,
|
|
|
|
|
size_t *len, size_t max);
|
|
|
|
|
int process_request_key_err(long err_code);
|
|
|
|
|
int
|
|
|
|
|
ecryptfs_parse_packet_set(struct ecryptfs_crypt_stat *crypt_stat,
|
|
|
|
|
unsigned char *src, struct dentry *ecryptfs_dentry);
|
|
|
|
|
int ecryptfs_truncate(struct dentry *dentry, loff_t new_length);
|
|
|
|
|
int
|
2006-10-31 06:07:18 +00:00
|
|
|
ecryptfs_process_cipher(struct crypto_blkcipher **key_tfm, char *cipher_name,
|
2006-10-31 06:07:16 +00:00
|
|
|
size_t *key_size);
|
2006-10-04 09:16:22 +00:00
|
|
|
int ecryptfs_inode_test(struct inode *inode, void *candidate_lower_inode);
|
|
|
|
|
int ecryptfs_inode_set(struct inode *inode, void *lower_inode);
|
|
|
|
|
void ecryptfs_init_inode(struct inode *inode, struct inode *lower_inode);
|
2006-10-31 06:07:19 +00:00
|
|
|
int ecryptfs_open_lower_file(struct file **lower_file,
|
|
|
|
|
struct dentry *lower_dentry,
|
|
|
|
|
struct vfsmount *lower_mnt, int flags);
|
|
|
|
|
int ecryptfs_close_lower_file(struct file *lower_file);
|
2007-02-12 08:53:46 +00:00
|
|
|
ssize_t ecryptfs_getxattr(struct dentry *dentry, const char *name, void *value,
|
|
|
|
|
size_t size);
|
|
|
|
|
int
|
|
|
|
|
ecryptfs_setxattr(struct dentry *dentry, const char *name, const void *value,
|
|
|
|
|
size_t size, int flags);
|
2007-02-12 08:53:47 +00:00
|
|
|
int ecryptfs_read_xattr_region(char *page_virt, struct dentry *ecryptfs_dentry);
|
[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>
2007-02-12 08:53:43 +00:00
|
|
|
int ecryptfs_process_helo(unsigned int transport, uid_t uid, pid_t pid);
|
|
|
|
|
int ecryptfs_process_quit(uid_t uid, pid_t pid);
|
2007-02-12 08:53:44 +00:00
|
|
|
int ecryptfs_process_response(struct ecryptfs_message *msg, uid_t uid,
|
|
|
|
|
pid_t pid, u32 seq);
|
[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>
2007-02-12 08:53:43 +00:00
|
|
|
int ecryptfs_send_message(unsigned int transport, char *data, int data_len,
|
|
|
|
|
struct ecryptfs_msg_ctx **msg_ctx);
|
|
|
|
|
int ecryptfs_wait_for_response(struct ecryptfs_msg_ctx *msg_ctx,
|
|
|
|
|
struct ecryptfs_message **emsg);
|
|
|
|
|
int ecryptfs_init_messaging(unsigned int transport);
|
|
|
|
|
void ecryptfs_release_messaging(unsigned int transport);
|
|
|
|
|
|
|
|
|
|
int ecryptfs_send_netlink(char *data, int data_len,
|
|
|
|
|
struct ecryptfs_msg_ctx *msg_ctx, u16 msg_type,
|
|
|
|
|
u16 msg_flags, pid_t daemon_pid);
|
|
|
|
|
int ecryptfs_init_netlink(void);
|
|
|
|
|
void ecryptfs_release_netlink(void);
|
|
|
|
|
|
|
|
|
|
int ecryptfs_send_connector(char *data, int data_len,
|
|
|
|
|
struct ecryptfs_msg_ctx *msg_ctx, u16 msg_type,
|
|
|
|
|
u16 msg_flags, pid_t daemon_pid);
|
|
|
|
|
int ecryptfs_init_connector(void);
|
|
|
|
|
void ecryptfs_release_connector(void);
|
2007-02-12 08:53:47 +00:00
|
|
|
void
|
|
|
|
|
ecryptfs_write_header_metadata(char *virt,
|
|
|
|
|
struct ecryptfs_crypt_stat *crypt_stat,
|
|
|
|
|
size_t *written);
|
[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>
2007-02-12 08:53:43 +00:00
|
|
|
|
2006-10-04 09:16:22 +00:00
|
|
|
#endif /* #ifndef ECRYPTFS_KERNEL_H */
|