2019-05-30 07:57:47 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
[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 16:53:43 +08:00
|
|
|
/**
|
|
|
|
|
* eCryptfs: Linux filesystem encryption layer
|
|
|
|
|
*
|
2008-04-29 15:59:51 +08:00
|
|
|
* Copyright (C) 2004-2008 International Business Machines Corp.
|
[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 16:53:43 +08:00
|
|
|
* Author(s): Michael A. Halcrow <mhalcrow@us.ibm.com>
|
|
|
|
|
* Tyler Hicks <tyhicks@ou.edu>
|
|
|
|
|
*/
|
Detach sched.h from mm.h
First thing mm.h does is including sched.h solely for can_do_mlock() inline
function which has "current" dereference inside. By dealing with can_do_mlock()
mm.h can be detached from sched.h which is good. See below, why.
This patch
a) removes unconditional inclusion of sched.h from mm.h
b) makes can_do_mlock() normal function in mm/mlock.c
c) exports can_do_mlock() to not break compilation
d) adds sched.h inclusions back to files that were getting it indirectly.
e) adds less bloated headers to some files (asm/signal.h, jiffies.h) that were
getting them indirectly
Net result is:
a) mm.h users would get less code to open, read, preprocess, parse, ... if
they don't need sched.h
b) sched.h stops being dependency for significant number of files:
on x86_64 allmodconfig touching sched.h results in recompile of 4083 files,
after patch it's only 3744 (-8.3%).
Cross-compile tested on
all arm defconfigs, all mips defconfigs, all powerpc defconfigs,
alpha alpha-up
arm
i386 i386-up i386-defconfig i386-allnoconfig
ia64 ia64-up
m68k
mips
parisc parisc-up
powerpc powerpc-up
s390 s390-up
sparc sparc-up
sparc64 sparc64-up
um-x86_64
x86_64 x86_64-up x86_64-defconfig x86_64-allnoconfig
as well as my two usual configs.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-05-21 05:22:52 +08:00
|
|
|
#include <linux/sched.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
2008-04-29 15:59:52 +08:00
|
|
|
#include <linux/user_namespace.h>
|
|
|
|
|
#include <linux/nsproxy.h>
|
[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 16:53:43 +08:00
|
|
|
#include "ecryptfs_kernel.h"
|
|
|
|
|
|
2007-02-12 16:53:46 +08:00
|
|
|
static LIST_HEAD(ecryptfs_msg_ctx_free_list);
|
|
|
|
|
static LIST_HEAD(ecryptfs_msg_ctx_alloc_list);
|
|
|
|
|
static struct mutex ecryptfs_msg_ctx_lists_mux;
|
[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 16:53:43 +08:00
|
|
|
|
2008-04-29 15:59:51 +08:00
|
|
|
static struct hlist_head *ecryptfs_daemon_hash;
|
|
|
|
|
struct mutex ecryptfs_daemon_hash_mux;
|
2010-07-14 04:59:17 +08:00
|
|
|
static int ecryptfs_hash_bits;
|
2012-06-12 00:47:47 +08:00
|
|
|
#define ecryptfs_current_euid_hash(uid) \
|
2012-02-08 08:24:33 +08:00
|
|
|
hash_long((unsigned long)from_kuid(&init_user_ns, current_euid()), ecryptfs_hash_bits)
|
[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 16:53:43 +08:00
|
|
|
|
2008-04-29 15:59:51 +08:00
|
|
|
static u32 ecryptfs_msg_counter;
|
2007-02-12 16:53:46 +08:00
|
|
|
static struct ecryptfs_msg_ctx *ecryptfs_msg_ctx_arr;
|
[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 16:53:43 +08:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* ecryptfs_acquire_free_msg_ctx
|
|
|
|
|
* @msg_ctx: The context that was acquired from the free list
|
|
|
|
|
*
|
|
|
|
|
* Acquires a context element from the free list and locks the mutex
|
2008-04-29 15:59:51 +08:00
|
|
|
* on the context. Sets the msg_ctx task to current. Returns zero on
|
|
|
|
|
* success; non-zero on error or upon failure to acquire a free
|
|
|
|
|
* context element. Must be called with ecryptfs_msg_ctx_lists_mux
|
|
|
|
|
* held.
|
[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 16:53:43 +08:00
|
|
|
*/
|
|
|
|
|
static int ecryptfs_acquire_free_msg_ctx(struct ecryptfs_msg_ctx **msg_ctx)
|
|
|
|
|
{
|
|
|
|
|
struct list_head *p;
|
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
|
|
if (list_empty(&ecryptfs_msg_ctx_free_list)) {
|
2008-04-29 15:59:51 +08:00
|
|
|
printk(KERN_WARNING "%s: The eCryptfs free "
|
|
|
|
|
"context list is empty. It may be helpful to "
|
|
|
|
|
"specify the ecryptfs_message_buf_len "
|
|
|
|
|
"parameter to be greater than the current "
|
|
|
|
|
"value of [%d]\n", __func__, ecryptfs_message_buf_len);
|
[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 16:53:43 +08:00
|
|
|
rc = -ENOMEM;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
list_for_each(p, &ecryptfs_msg_ctx_free_list) {
|
|
|
|
|
*msg_ctx = list_entry(p, struct ecryptfs_msg_ctx, node);
|
|
|
|
|
if (mutex_trylock(&(*msg_ctx)->mux)) {
|
|
|
|
|
(*msg_ctx)->task = current;
|
|
|
|
|
rc = 0;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
rc = -ENOMEM;
|
|
|
|
|
out:
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* ecryptfs_msg_ctx_free_to_alloc
|
|
|
|
|
* @msg_ctx: The context to move from the free list to the alloc list
|
|
|
|
|
*
|
2008-04-29 15:59:51 +08:00
|
|
|
* Must be called with ecryptfs_msg_ctx_lists_mux held.
|
[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 16:53:43 +08:00
|
|
|
*/
|
|
|
|
|
static void ecryptfs_msg_ctx_free_to_alloc(struct ecryptfs_msg_ctx *msg_ctx)
|
|
|
|
|
{
|
|
|
|
|
list_move(&msg_ctx->node, &ecryptfs_msg_ctx_alloc_list);
|
|
|
|
|
msg_ctx->state = ECRYPTFS_MSG_CTX_STATE_PENDING;
|
|
|
|
|
msg_ctx->counter = ++ecryptfs_msg_counter;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* ecryptfs_msg_ctx_alloc_to_free
|
|
|
|
|
* @msg_ctx: The context to move from the alloc list to the free list
|
|
|
|
|
*
|
2008-04-29 15:59:51 +08:00
|
|
|
* Must be called with ecryptfs_msg_ctx_lists_mux held.
|
[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 16:53:43 +08:00
|
|
|
*/
|
2008-04-29 15:59:51 +08:00
|
|
|
void ecryptfs_msg_ctx_alloc_to_free(struct ecryptfs_msg_ctx *msg_ctx)
|
[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 16:53:43 +08:00
|
|
|
{
|
|
|
|
|
list_move(&(msg_ctx->node), &ecryptfs_msg_ctx_free_list);
|
2013-02-13 02:03:49 +08:00
|
|
|
kfree(msg_ctx->msg);
|
2008-04-29 15:59:51 +08:00
|
|
|
msg_ctx->msg = NULL;
|
[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 16:53:43 +08:00
|
|
|
msg_ctx->state = ECRYPTFS_MSG_CTX_STATE_FREE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2008-04-29 15:59:51 +08:00
|
|
|
* ecryptfs_find_daemon_by_euid
|
|
|
|
|
* @daemon: If return value is zero, points to the desired daemon pointer
|
[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 16:53:43 +08:00
|
|
|
*
|
2008-04-29 15:59:51 +08:00
|
|
|
* Must be called with ecryptfs_daemon_hash_mux held.
|
|
|
|
|
*
|
2012-06-12 00:47:47 +08:00
|
|
|
* Search the hash list for the current effective user id.
|
2008-04-29 15:59:51 +08:00
|
|
|
*
|
|
|
|
|
* Returns zero if the user id exists in the list; non-zero otherwise.
|
[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 16:53:43 +08:00
|
|
|
*/
|
2012-06-12 00:47:47 +08:00
|
|
|
int ecryptfs_find_daemon_by_euid(struct ecryptfs_daemon **daemon)
|
[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 16:53:43 +08:00
|
|
|
{
|
|
|
|
|
int rc;
|
|
|
|
|
|
hlist: drop the node parameter from iterators
I'm not sure why, but the hlist for each entry iterators were conceived
list_for_each_entry(pos, head, member)
The hlist ones were greedy and wanted an extra parameter:
hlist_for_each_entry(tpos, pos, head, member)
Why did they need an extra pos parameter? I'm not quite sure. Not only
they don't really need it, it also prevents the iterator from looking
exactly like the list iterator, which is unfortunate.
Besides the semantic patch, there was some manual work required:
- Fix up the actual hlist iterators in linux/list.h
- Fix up the declaration of other iterators based on the hlist ones.
- A very small amount of places were using the 'node' parameter, this
was modified to use 'obj->member' instead.
- Coccinelle didn't handle the hlist_for_each_entry_safe iterator
properly, so those had to be fixed up manually.
The semantic patch which is mostly the work of Peter Senna Tschudin is here:
@@
iterator name hlist_for_each_entry, hlist_for_each_entry_continue, hlist_for_each_entry_from, hlist_for_each_entry_rcu, hlist_for_each_entry_rcu_bh, hlist_for_each_entry_continue_rcu_bh, for_each_busy_worker, ax25_uid_for_each, ax25_for_each, inet_bind_bucket_for_each, sctp_for_each_hentry, sk_for_each, sk_for_each_rcu, sk_for_each_from, sk_for_each_safe, sk_for_each_bound, hlist_for_each_entry_safe, hlist_for_each_entry_continue_rcu, nr_neigh_for_each, nr_neigh_for_each_safe, nr_node_for_each, nr_node_for_each_safe, for_each_gfn_indirect_valid_sp, for_each_gfn_sp, for_each_host;
type T;
expression a,c,d,e;
identifier b;
statement S;
@@
-T b;
<+... when != b
(
hlist_for_each_entry(a,
- b,
c, d) S
|
hlist_for_each_entry_continue(a,
- b,
c) S
|
hlist_for_each_entry_from(a,
- b,
c) S
|
hlist_for_each_entry_rcu(a,
- b,
c, d) S
|
hlist_for_each_entry_rcu_bh(a,
- b,
c, d) S
|
hlist_for_each_entry_continue_rcu_bh(a,
- b,
c) S
|
for_each_busy_worker(a, c,
- b,
d) S
|
ax25_uid_for_each(a,
- b,
c) S
|
ax25_for_each(a,
- b,
c) S
|
inet_bind_bucket_for_each(a,
- b,
c) S
|
sctp_for_each_hentry(a,
- b,
c) S
|
sk_for_each(a,
- b,
c) S
|
sk_for_each_rcu(a,
- b,
c) S
|
sk_for_each_from
-(a, b)
+(a)
S
+ sk_for_each_from(a) S
|
sk_for_each_safe(a,
- b,
c, d) S
|
sk_for_each_bound(a,
- b,
c) S
|
hlist_for_each_entry_safe(a,
- b,
c, d, e) S
|
hlist_for_each_entry_continue_rcu(a,
- b,
c) S
|
nr_neigh_for_each(a,
- b,
c) S
|
nr_neigh_for_each_safe(a,
- b,
c, d) S
|
nr_node_for_each(a,
- b,
c) S
|
nr_node_for_each_safe(a,
- b,
c, d) S
|
- for_each_gfn_sp(a, c, d, b) S
+ for_each_gfn_sp(a, c, d) S
|
- for_each_gfn_indirect_valid_sp(a, c, d, b) S
+ for_each_gfn_indirect_valid_sp(a, c, d) S
|
for_each_host(a,
- b,
c) S
|
for_each_host_safe(a,
- b,
c, d) S
|
for_each_mesh_entry(a,
- b,
c, d) S
)
...+>
[akpm@linux-foundation.org: drop bogus change from net/ipv4/raw.c]
[akpm@linux-foundation.org: drop bogus hunk from net/ipv6/raw.c]
[akpm@linux-foundation.org: checkpatch fixes]
[akpm@linux-foundation.org: fix warnings]
[akpm@linux-foudnation.org: redo intrusive kvm changes]
Tested-by: Peter Senna Tschudin <peter.senna@gmail.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-02-28 09:06:00 +08:00
|
|
|
hlist_for_each_entry(*daemon,
|
2012-06-12 00:47:47 +08:00
|
|
|
&ecryptfs_daemon_hash[ecryptfs_current_euid_hash()],
|
|
|
|
|
euid_chain) {
|
2012-02-08 08:24:33 +08:00
|
|
|
if (uid_eq((*daemon)->file->f_cred->euid, current_euid())) {
|
[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 16:53:43 +08:00
|
|
|
rc = 0;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
rc = -EINVAL;
|
|
|
|
|
out:
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
2008-04-29 15:59:51 +08:00
|
|
|
/**
|
|
|
|
|
* ecryptfs_spawn_daemon - Create and initialize a new daemon struct
|
|
|
|
|
* @daemon: Pointer to set to newly allocated daemon struct
|
2012-06-12 00:47:47 +08:00
|
|
|
* @file: File used when opening /dev/ecryptfs
|
2008-04-29 15:59:51 +08:00
|
|
|
*
|
|
|
|
|
* Must be called ceremoniously while in possession of
|
|
|
|
|
* ecryptfs_sacred_daemon_hash_mux
|
|
|
|
|
*
|
|
|
|
|
* Returns zero on success; non-zero otherwise
|
|
|
|
|
*/
|
|
|
|
|
int
|
2012-06-12 00:47:47 +08:00
|
|
|
ecryptfs_spawn_daemon(struct ecryptfs_daemon **daemon, struct file *file)
|
2008-04-29 15:59:51 +08:00
|
|
|
{
|
|
|
|
|
int rc = 0;
|
|
|
|
|
|
|
|
|
|
(*daemon) = kzalloc(sizeof(**daemon), GFP_KERNEL);
|
|
|
|
|
if (!(*daemon)) {
|
|
|
|
|
rc = -ENOMEM;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
2012-06-12 00:47:47 +08:00
|
|
|
(*daemon)->file = file;
|
2008-04-29 15:59:51 +08:00
|
|
|
mutex_init(&(*daemon)->mux);
|
|
|
|
|
INIT_LIST_HEAD(&(*daemon)->msg_ctx_out_queue);
|
|
|
|
|
init_waitqueue_head(&(*daemon)->wait);
|
|
|
|
|
(*daemon)->num_queued_msg_ctx = 0;
|
|
|
|
|
hlist_add_head(&(*daemon)->euid_chain,
|
2012-06-12 00:47:47 +08:00
|
|
|
&ecryptfs_daemon_hash[ecryptfs_current_euid_hash()]);
|
2008-04-29 15:59:51 +08:00
|
|
|
out:
|
[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 16:53:43 +08:00
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
2008-04-29 15:59:51 +08:00
|
|
|
/**
|
|
|
|
|
* ecryptfs_exorcise_daemon - Destroy the daemon struct
|
|
|
|
|
*
|
|
|
|
|
* Must be called ceremoniously while in possession of
|
|
|
|
|
* ecryptfs_daemon_hash_mux and the daemon's own mux.
|
|
|
|
|
*/
|
|
|
|
|
int ecryptfs_exorcise_daemon(struct ecryptfs_daemon *daemon)
|
|
|
|
|
{
|
|
|
|
|
struct ecryptfs_msg_ctx *msg_ctx, *msg_ctx_tmp;
|
|
|
|
|
int rc = 0;
|
|
|
|
|
|
|
|
|
|
mutex_lock(&daemon->mux);
|
|
|
|
|
if ((daemon->flags & ECRYPTFS_DAEMON_IN_READ)
|
|
|
|
|
|| (daemon->flags & ECRYPTFS_DAEMON_IN_POLL)) {
|
|
|
|
|
rc = -EBUSY;
|
|
|
|
|
mutex_unlock(&daemon->mux);
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
list_for_each_entry_safe(msg_ctx, msg_ctx_tmp,
|
|
|
|
|
&daemon->msg_ctx_out_queue, daemon_out_list) {
|
|
|
|
|
list_del(&msg_ctx->daemon_out_list);
|
|
|
|
|
daemon->num_queued_msg_ctx--;
|
|
|
|
|
printk(KERN_WARNING "%s: Warning: dropping message that is in "
|
|
|
|
|
"the out queue of a dying daemon\n", __func__);
|
|
|
|
|
ecryptfs_msg_ctx_alloc_to_free(msg_ctx);
|
|
|
|
|
}
|
|
|
|
|
hlist_del(&daemon->euid_chain);
|
|
|
|
|
mutex_unlock(&daemon->mux);
|
2009-04-01 06:24:42 +08:00
|
|
|
kzfree(daemon);
|
2008-04-29 15:59:51 +08:00
|
|
|
out:
|
[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 16:53:43 +08:00
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* ecryptfs_process_reponse
|
|
|
|
|
* @msg: The ecryptfs message received; the caller should sanity check
|
2008-04-29 15:59:51 +08:00
|
|
|
* msg->data_len and free the memory
|
|
|
|
|
* @seq: The sequence number of the message; must match the sequence
|
|
|
|
|
* number for the existing message context waiting for this
|
|
|
|
|
* response
|
|
|
|
|
*
|
|
|
|
|
* Processes a response message after sending an operation request to
|
|
|
|
|
* userspace. Some other process is awaiting this response. Before
|
|
|
|
|
* sending out its first communications, the other process allocated a
|
|
|
|
|
* msg_ctx from the ecryptfs_msg_ctx_arr at a particular index. The
|
|
|
|
|
* response message contains this index so that we can copy over the
|
|
|
|
|
* response message into the msg_ctx that the process holds a
|
|
|
|
|
* reference to. The other process is going to wake up, check to see
|
|
|
|
|
* that msg_ctx->state == ECRYPTFS_MSG_CTX_STATE_DONE, and then
|
|
|
|
|
* proceed to read off and process the response message. Returns zero
|
|
|
|
|
* upon delivery to desired context element; non-zero upon delivery
|
|
|
|
|
* failure or error.
|
[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 16:53:43 +08:00
|
|
|
*
|
2008-04-29 15:59:51 +08:00
|
|
|
* Returns zero on success; non-zero otherwise
|
[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 16:53:43 +08:00
|
|
|
*/
|
2012-06-12 00:47:47 +08:00
|
|
|
int ecryptfs_process_response(struct ecryptfs_daemon *daemon,
|
|
|
|
|
struct ecryptfs_message *msg, 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 16:53:43 +08:00
|
|
|
{
|
|
|
|
|
struct ecryptfs_msg_ctx *msg_ctx;
|
2008-04-29 15:59:51 +08:00
|
|
|
size_t msg_size;
|
[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 16:53:43 +08:00
|
|
|
int rc;
|
|
|
|
|
|
|
|
|
|
if (msg->index >= ecryptfs_message_buf_len) {
|
|
|
|
|
rc = -EINVAL;
|
2008-04-29 15:59:51 +08:00
|
|
|
printk(KERN_ERR "%s: Attempt to reference "
|
|
|
|
|
"context buffer at index [%d]; maximum "
|
|
|
|
|
"allowable is [%d]\n", __func__, msg->index,
|
|
|
|
|
(ecryptfs_message_buf_len - 1));
|
[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 16:53:43 +08:00
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
msg_ctx = &ecryptfs_msg_ctx_arr[msg->index];
|
|
|
|
|
mutex_lock(&msg_ctx->mux);
|
|
|
|
|
if (msg_ctx->state != ECRYPTFS_MSG_CTX_STATE_PENDING) {
|
|
|
|
|
rc = -EINVAL;
|
2008-04-29 15:59:51 +08:00
|
|
|
printk(KERN_WARNING "%s: Desired context element is not "
|
|
|
|
|
"pending a response\n", __func__);
|
[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 16:53:43 +08:00
|
|
|
goto unlock;
|
|
|
|
|
} else if (msg_ctx->counter != seq) {
|
|
|
|
|
rc = -EINVAL;
|
2008-04-29 15:59:51 +08:00
|
|
|
printk(KERN_WARNING "%s: Invalid message sequence; "
|
|
|
|
|
"expected [%d]; received [%d]\n", __func__,
|
|
|
|
|
msg_ctx->counter, 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 16:53:43 +08:00
|
|
|
goto unlock;
|
|
|
|
|
}
|
2008-04-29 15:59:51 +08:00
|
|
|
msg_size = (sizeof(*msg) + msg->data_len);
|
2013-06-01 17:39:36 +08:00
|
|
|
msg_ctx->msg = kmemdup(msg, msg_size, GFP_KERNEL);
|
[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 16:53:43 +08:00
|
|
|
if (!msg_ctx->msg) {
|
|
|
|
|
rc = -ENOMEM;
|
|
|
|
|
goto unlock;
|
|
|
|
|
}
|
|
|
|
|
msg_ctx->state = ECRYPTFS_MSG_CTX_STATE_DONE;
|
|
|
|
|
wake_up_process(msg_ctx->task);
|
2012-06-12 00:47:47 +08:00
|
|
|
rc = 0;
|
[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 16:53:43 +08:00
|
|
|
unlock:
|
|
|
|
|
mutex_unlock(&msg_ctx->mux);
|
|
|
|
|
out:
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2008-04-29 15:59:51 +08:00
|
|
|
* ecryptfs_send_message_locked
|
[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 16:53:43 +08:00
|
|
|
* @data: The data to send
|
|
|
|
|
* @data_len: The length of data
|
|
|
|
|
* @msg_ctx: The message context allocated for the send
|
2008-04-29 15:59:51 +08:00
|
|
|
*
|
|
|
|
|
* Must be called with ecryptfs_daemon_hash_mux held.
|
|
|
|
|
*
|
|
|
|
|
* Returns zero on success; non-zero otherwise
|
[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 16:53:43 +08:00
|
|
|
*/
|
2008-04-29 15:59:51 +08:00
|
|
|
static int
|
2008-10-16 13:02:51 +08:00
|
|
|
ecryptfs_send_message_locked(char *data, int data_len, u8 msg_type,
|
|
|
|
|
struct ecryptfs_msg_ctx **msg_ctx)
|
[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 16:53:43 +08:00
|
|
|
{
|
2008-04-29 15:59:51 +08:00
|
|
|
struct ecryptfs_daemon *daemon;
|
[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 16:53:43 +08:00
|
|
|
int rc;
|
|
|
|
|
|
2012-06-12 00:47:47 +08:00
|
|
|
rc = ecryptfs_find_daemon_by_euid(&daemon);
|
2013-02-28 03:37:48 +08:00
|
|
|
if (rc) {
|
[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 16:53:43 +08:00
|
|
|
rc = -ENOTCONN;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
mutex_lock(&ecryptfs_msg_ctx_lists_mux);
|
|
|
|
|
rc = ecryptfs_acquire_free_msg_ctx(msg_ctx);
|
|
|
|
|
if (rc) {
|
|
|
|
|
mutex_unlock(&ecryptfs_msg_ctx_lists_mux);
|
2008-04-29 15:59:51 +08:00
|
|
|
printk(KERN_WARNING "%s: Could not claim a free "
|
|
|
|
|
"context element\n", __func__);
|
[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 16:53:43 +08:00
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
ecryptfs_msg_ctx_free_to_alloc(*msg_ctx);
|
|
|
|
|
mutex_unlock(&(*msg_ctx)->mux);
|
|
|
|
|
mutex_unlock(&ecryptfs_msg_ctx_lists_mux);
|
2008-10-16 13:02:51 +08:00
|
|
|
rc = ecryptfs_send_miscdev(data, data_len, *msg_ctx, msg_type, 0,
|
|
|
|
|
daemon);
|
2008-04-29 15:59:51 +08:00
|
|
|
if (rc)
|
|
|
|
|
printk(KERN_ERR "%s: Error attempting to send message to "
|
|
|
|
|
"userspace daemon; rc = [%d]\n", __func__, rc);
|
[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 16:53:43 +08:00
|
|
|
out:
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
2008-04-29 15:59:51 +08:00
|
|
|
/**
|
|
|
|
|
* ecryptfs_send_message
|
|
|
|
|
* @data: The data to send
|
|
|
|
|
* @data_len: The length of data
|
|
|
|
|
* @msg_ctx: The message context allocated for the send
|
|
|
|
|
*
|
|
|
|
|
* Grabs ecryptfs_daemon_hash_mux.
|
|
|
|
|
*
|
|
|
|
|
* Returns zero on success; non-zero otherwise
|
|
|
|
|
*/
|
2008-10-16 13:02:51 +08:00
|
|
|
int ecryptfs_send_message(char *data, int data_len,
|
2008-04-29 15:59:51 +08:00
|
|
|
struct ecryptfs_msg_ctx **msg_ctx)
|
|
|
|
|
{
|
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
|
|
mutex_lock(&ecryptfs_daemon_hash_mux);
|
2008-10-16 13:02:51 +08:00
|
|
|
rc = ecryptfs_send_message_locked(data, data_len, ECRYPTFS_MSG_REQUEST,
|
|
|
|
|
msg_ctx);
|
2008-04-29 15:59:51 +08:00
|
|
|
mutex_unlock(&ecryptfs_daemon_hash_mux);
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
[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 16:53:43 +08:00
|
|
|
/**
|
|
|
|
|
* ecryptfs_wait_for_response
|
|
|
|
|
* @msg_ctx: The context that was assigned when sending a message
|
|
|
|
|
* @msg: The incoming message from userspace; not set if rc != 0
|
|
|
|
|
*
|
|
|
|
|
* Sleeps until awaken by ecryptfs_receive_message or until the amount
|
|
|
|
|
* of time exceeds ecryptfs_message_wait_timeout. If zero is
|
|
|
|
|
* returned, msg will point to a valid message from userspace; a
|
|
|
|
|
* non-zero value is returned upon failure to receive a message or an
|
2008-04-29 15:59:51 +08:00
|
|
|
* error occurs. Callee must free @msg on success.
|
[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 16:53:43 +08:00
|
|
|
*/
|
|
|
|
|
int ecryptfs_wait_for_response(struct ecryptfs_msg_ctx *msg_ctx,
|
|
|
|
|
struct ecryptfs_message **msg)
|
|
|
|
|
{
|
|
|
|
|
signed long timeout = ecryptfs_message_wait_timeout * HZ;
|
|
|
|
|
int rc = 0;
|
|
|
|
|
|
|
|
|
|
sleep:
|
|
|
|
|
timeout = schedule_timeout_interruptible(timeout);
|
|
|
|
|
mutex_lock(&ecryptfs_msg_ctx_lists_mux);
|
|
|
|
|
mutex_lock(&msg_ctx->mux);
|
|
|
|
|
if (msg_ctx->state != ECRYPTFS_MSG_CTX_STATE_DONE) {
|
|
|
|
|
if (timeout) {
|
|
|
|
|
mutex_unlock(&msg_ctx->mux);
|
|
|
|
|
mutex_unlock(&ecryptfs_msg_ctx_lists_mux);
|
|
|
|
|
goto sleep;
|
|
|
|
|
}
|
|
|
|
|
rc = -ENOMSG;
|
|
|
|
|
} else {
|
|
|
|
|
*msg = msg_ctx->msg;
|
|
|
|
|
msg_ctx->msg = NULL;
|
|
|
|
|
}
|
|
|
|
|
ecryptfs_msg_ctx_alloc_to_free(msg_ctx);
|
|
|
|
|
mutex_unlock(&msg_ctx->mux);
|
|
|
|
|
mutex_unlock(&ecryptfs_msg_ctx_lists_mux);
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
2010-08-17 23:24:05 +08:00
|
|
|
int __init ecryptfs_init_messaging(void)
|
[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 16:53:43 +08:00
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
int rc = 0;
|
|
|
|
|
|
|
|
|
|
if (ecryptfs_number_of_users > ECRYPTFS_MAX_NUM_USERS) {
|
|
|
|
|
ecryptfs_number_of_users = ECRYPTFS_MAX_NUM_USERS;
|
2008-04-29 15:59:51 +08:00
|
|
|
printk(KERN_WARNING "%s: Specified number of users is "
|
|
|
|
|
"too large, defaulting to [%d] users\n", __func__,
|
|
|
|
|
ecryptfs_number_of_users);
|
[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 16:53:43 +08:00
|
|
|
}
|
2008-04-29 15:59:51 +08:00
|
|
|
mutex_init(&ecryptfs_daemon_hash_mux);
|
|
|
|
|
mutex_lock(&ecryptfs_daemon_hash_mux);
|
2010-07-14 04:59:17 +08:00
|
|
|
ecryptfs_hash_bits = 1;
|
|
|
|
|
while (ecryptfs_number_of_users >> ecryptfs_hash_bits)
|
|
|
|
|
ecryptfs_hash_bits++;
|
2008-04-29 15:59:51 +08:00
|
|
|
ecryptfs_daemon_hash = kmalloc((sizeof(struct hlist_head)
|
2010-07-14 04:59:17 +08:00
|
|
|
* (1 << ecryptfs_hash_bits)),
|
|
|
|
|
GFP_KERNEL);
|
2008-04-29 15:59:51 +08:00
|
|
|
if (!ecryptfs_daemon_hash) {
|
[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 16:53:43 +08:00
|
|
|
rc = -ENOMEM;
|
2008-04-29 15:59:51 +08:00
|
|
|
mutex_unlock(&ecryptfs_daemon_hash_mux);
|
[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 16:53:43 +08:00
|
|
|
goto out;
|
|
|
|
|
}
|
2010-07-14 04:59:17 +08:00
|
|
|
for (i = 0; i < (1 << ecryptfs_hash_bits); i++)
|
2008-04-29 15:59:51 +08:00
|
|
|
INIT_HLIST_HEAD(&ecryptfs_daemon_hash[i]);
|
|
|
|
|
mutex_unlock(&ecryptfs_daemon_hash_mux);
|
[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 16:53:43 +08:00
|
|
|
ecryptfs_msg_ctx_arr = kmalloc((sizeof(struct ecryptfs_msg_ctx)
|
2008-04-29 15:59:51 +08:00
|
|
|
* ecryptfs_message_buf_len),
|
|
|
|
|
GFP_KERNEL);
|
[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 16:53:43 +08:00
|
|
|
if (!ecryptfs_msg_ctx_arr) {
|
2024-06-11 20:08:33 +08:00
|
|
|
kfree(ecryptfs_daemon_hash);
|
[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 16:53:43 +08:00
|
|
|
rc = -ENOMEM;
|
|
|
|
|
goto out;
|
|
|
|
|
}
|
|
|
|
|
mutex_init(&ecryptfs_msg_ctx_lists_mux);
|
|
|
|
|
mutex_lock(&ecryptfs_msg_ctx_lists_mux);
|
|
|
|
|
ecryptfs_msg_counter = 0;
|
|
|
|
|
for (i = 0; i < ecryptfs_message_buf_len; i++) {
|
|
|
|
|
INIT_LIST_HEAD(&ecryptfs_msg_ctx_arr[i].node);
|
2008-04-29 15:59:51 +08:00
|
|
|
INIT_LIST_HEAD(&ecryptfs_msg_ctx_arr[i].daemon_out_list);
|
[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 16:53:43 +08:00
|
|
|
mutex_init(&ecryptfs_msg_ctx_arr[i].mux);
|
|
|
|
|
mutex_lock(&ecryptfs_msg_ctx_arr[i].mux);
|
|
|
|
|
ecryptfs_msg_ctx_arr[i].index = i;
|
|
|
|
|
ecryptfs_msg_ctx_arr[i].state = ECRYPTFS_MSG_CTX_STATE_FREE;
|
|
|
|
|
ecryptfs_msg_ctx_arr[i].counter = 0;
|
|
|
|
|
ecryptfs_msg_ctx_arr[i].task = NULL;
|
|
|
|
|
ecryptfs_msg_ctx_arr[i].msg = NULL;
|
|
|
|
|
list_add_tail(&ecryptfs_msg_ctx_arr[i].node,
|
|
|
|
|
&ecryptfs_msg_ctx_free_list);
|
|
|
|
|
mutex_unlock(&ecryptfs_msg_ctx_arr[i].mux);
|
|
|
|
|
}
|
|
|
|
|
mutex_unlock(&ecryptfs_msg_ctx_lists_mux);
|
2008-10-16 13:02:51 +08:00
|
|
|
rc = ecryptfs_init_ecryptfs_miscdev();
|
|
|
|
|
if (rc)
|
|
|
|
|
ecryptfs_release_messaging();
|
[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 16:53:43 +08:00
|
|
|
out:
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
2008-10-16 13:02:51 +08:00
|
|
|
void ecryptfs_release_messaging(void)
|
[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 16:53:43 +08:00
|
|
|
{
|
|
|
|
|
if (ecryptfs_msg_ctx_arr) {
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
mutex_lock(&ecryptfs_msg_ctx_lists_mux);
|
|
|
|
|
for (i = 0; i < ecryptfs_message_buf_len; i++) {
|
|
|
|
|
mutex_lock(&ecryptfs_msg_ctx_arr[i].mux);
|
2014-06-17 02:06:12 +08:00
|
|
|
kfree(ecryptfs_msg_ctx_arr[i].msg);
|
[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 16:53:43 +08:00
|
|
|
mutex_unlock(&ecryptfs_msg_ctx_arr[i].mux);
|
|
|
|
|
}
|
|
|
|
|
kfree(ecryptfs_msg_ctx_arr);
|
|
|
|
|
mutex_unlock(&ecryptfs_msg_ctx_lists_mux);
|
|
|
|
|
}
|
2008-04-29 15:59:51 +08:00
|
|
|
if (ecryptfs_daemon_hash) {
|
|
|
|
|
struct ecryptfs_daemon *daemon;
|
2017-08-23 04:41:28 +08:00
|
|
|
struct hlist_node *n;
|
[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 16:53:43 +08:00
|
|
|
int i;
|
|
|
|
|
|
2008-04-29 15:59:51 +08:00
|
|
|
mutex_lock(&ecryptfs_daemon_hash_mux);
|
2010-07-14 04:59:17 +08:00
|
|
|
for (i = 0; i < (1 << ecryptfs_hash_bits); i++) {
|
2008-04-29 15:59:51 +08:00
|
|
|
int rc;
|
|
|
|
|
|
2017-08-23 04:41:28 +08:00
|
|
|
hlist_for_each_entry_safe(daemon, n,
|
|
|
|
|
&ecryptfs_daemon_hash[i],
|
|
|
|
|
euid_chain) {
|
2008-04-29 15:59:51 +08:00
|
|
|
rc = ecryptfs_exorcise_daemon(daemon);
|
|
|
|
|
if (rc)
|
|
|
|
|
printk(KERN_ERR "%s: Error whilst "
|
|
|
|
|
"attempting to destroy daemon; "
|
|
|
|
|
"rc = [%d]. Dazed and confused, "
|
|
|
|
|
"but trying to continue.\n",
|
|
|
|
|
__func__, rc);
|
[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 16:53:43 +08:00
|
|
|
}
|
|
|
|
|
}
|
2008-04-29 15:59:51 +08:00
|
|
|
kfree(ecryptfs_daemon_hash);
|
|
|
|
|
mutex_unlock(&ecryptfs_daemon_hash_mux);
|
[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 16:53:43 +08:00
|
|
|
}
|
2008-10-16 13:02:51 +08:00
|
|
|
ecryptfs_destroy_ecryptfs_miscdev();
|
[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 16:53:43 +08:00
|
|
|
return;
|
|
|
|
|
}
|