22 Apr, 2009
1 commit
-
ecryptfs_passthrough is a mount option that allows eCryptfs to allow
data to be written to non-eCryptfs files in the lower filesystem. The
passthrough option was causing data corruption due to it not always
being treated as a non-eCryptfs file.The first 8 bytes of an eCryptfs file contains the decrypted file size.
This value was being written to the non-eCryptfs files, too. Also,
extra 0x00 characters were being written to make the file size a
multiple of PAGE_CACHE_SIZE.Signed-off-by: Tyler Hicks
23 Mar, 2009
2 commits
-
If ecryptfs_encrypted_view or ecryptfs_xattr_metadata were being
specified as mount options, a NULL pointer dereference of crypt_stat
was possible during lookup.This patch moves the crypt_stat assignment into
ecryptfs_lookup_and_interpose_lower(), ensuring that crypt_stat
will not be NULL before we attempt to dereference it.Thanks to Dan Carpenter and his static analysis tool, smatch, for
finding this bug.Signed-off-by: Tyler Hicks
Acked-by: Dustin Kirkland
Cc: Dan Carpenter
Cc: Serge Hallyn
Signed-off-by: Linus Torvalds -
When allocating the memory used to store the eCryptfs header contents, a
single, zeroed page was being allocated with get_zeroed_page().
However, the size of an eCryptfs header is either PAGE_CACHE_SIZE or
ECRYPTFS_MINIMUM_HEADER_EXTENT_SIZE (8192), whichever is larger, and is
stored in the file's private_data->crypt_stat->num_header_bytes_at_front
field.ecryptfs_write_metadata_to_contents() was using
num_header_bytes_at_front to decide how many bytes should be written to
the lower filesystem for the file header. Unfortunately, at least 8K
was being written from the page, despite the chance of the single,
zeroed page being smaller than 8K. This resulted in random areas of
kernel memory being written between the 0x1000 and 0x1FFF bytes offsets
in the eCryptfs file headers if PAGE_SIZE was 4K.This patch allocates a variable number of pages, calculated with
num_header_bytes_at_front, and passes the number of allocated pages
along to ecryptfs_write_metadata_to_contents().Thanks to Florian Streibelt for reporting the data leak and working with
me to find the problem. 2.6.28 is the only kernel release with this
vulnerability. Corresponds to CVE-2009-0787Signed-off-by: Tyler Hicks
Acked-by: Dustin Kirkland
Reviewed-by: Eric Sandeen
Reviewed-by: Eugene Teo
Cc: Greg KH
Cc: dann frazier
Cc: Serge E. Hallyn
Cc: Florian Streibelt
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds
15 Mar, 2009
1 commit
-
eCryptfs has file encryption keys (FEK), file encryption key encryption
keys (FEKEK), and filename encryption keys (FNEK). The per-file FEK is
encrypted with one or more FEKEKs and stored in the header of the
encrypted file. I noticed that the FEK is also being encrypted by the
FNEK. This is a problem if a user wants to use a different FNEK than
their FEKEK, as their file contents will still be accessible with the
FNEK.This is a minimalistic patch which prevents the FNEKs signatures from
being copied to the inode signatures list. Ultimately, it keeps the FEK
from being encrypted with a FNEK.Signed-off-by: Tyler Hicks
Cc: Serge Hallyn
Acked-by: Dustin Kirkland
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Feb, 2009
1 commit
-
The addition of filename encryption caused a regression in unencrypted
filename symlink support. ecryptfs_copy_filename() is used when dealing
with unencrypted filenames and it reported that the new, copied filename
was a character longer than it should have been.This caused the return value of readlink() to count the NULL byte of the
symlink target. Most applications don't care about the extra NULL byte,
but a version control system (bzr) helped in discovering the bug.Signed-off-by: Tyler Hicks
Signed-off-by: Linus Torvalds
07 Jan, 2009
7 commits
-
Flesh out the comments for ecryptfs_decode_from_filename(). Remove the
return condition, since it is always 0.Signed-off-by: Michael Halcrow
Cc: Dustin Kirkland
Cc: Eric Sandeen
Cc: Tyler Hicks
Cc: David Kleikamp
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Correct several format string data type specifiers. Correct filename size
data types; they should be size_t rather than int when passed as
parameters to some other functions (although note that the filenames will
never be larger than int).Signed-off-by: Michael Halcrow
Cc: Dustin Kirkland
Cc: Eric Sandeen
Cc: Tyler Hicks
Cc: David Kleikamp
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
%Z is a gcc-ism. Using %z instead.
Signed-off-by: Michael Halcrow
Cc: Dustin Kirkland
Cc: Eric Sandeen
Cc: Tyler Hicks
Cc: David Kleikamp
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Make the requisite modifications to ecryptfs_filldir(), ecryptfs_lookup(),
and ecryptfs_readlink() to call out to filename encryption functions.
Propagate filename encryption policy flags from mount-wide crypt_stat to
inode crypt_stat.Signed-off-by: Michael Halcrow
Cc: Dustin Kirkland
Cc: Eric Sandeen
Cc: Tyler Hicks
Cc: David Kleikamp
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
These functions support encrypting and encoding the filename contents.
The encrypted filename contents may consist of any ASCII characters. This
patch includes a custom encoding mechanism to map the ASCII characters to
a reduced character set that is appropriate for filenames.Signed-off-by: Michael Halcrow
Cc: Dustin Kirkland
Cc: Eric Sandeen
Cc: Tyler Hicks
Cc: David Kleikamp
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Extensions to the header file to support filename encryption.
Signed-off-by: Michael Halcrow
Cc: Dustin Kirkland
Cc: Eric Sandeen
Cc: Tyler Hicks
Cc: David Kleikamp
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This patchset implements filename encryption via a passphrase-derived
mount-wide Filename Encryption Key (FNEK) specified as a mount parameter.
Each encrypted filename has a fixed prefix indicating that eCryptfs should
try to decrypt the filename. When eCryptfs encounters this prefix, it
decodes the filename into a tag 70 packet and then decrypts the packet
contents using the FNEK, setting the filename to the decrypted filename.
Both unencrypted and encrypted filenames can reside in the same lower
filesystem.Because filename encryption expands the length of the filename during the
encoding stage, eCryptfs will not properly handle filenames that are
already near the maximum filename length.In the present implementation, eCryptfs must be able to produce a match
against the lower encrypted and encoded filename representation when given
a plaintext filename. Therefore, two files having the same plaintext name
will encrypt and encode into the same lower filename if they are both
encrypted using the same FNEK. This can be changed by finding a way to
replace the prepended bytes in the blocked-aligned filename with random
characters; they are hashes of the FNEK right now, so that it is possible
to deterministically map from a plaintext filename to an encrypted and
encoded filename in the lower filesystem. An implementation using random
characters will have to decode and decrypt every single directory entry in
any given directory any time an event occurs wherein the VFS needs to
determine whether a particular file exists in the lower directory and the
decrypted and decoded filenames have not yet been extracted for that
directory.Thanks to Tyler Hicks and David Kleikamp for assistance in the development
of this patchset.This patch:
A tag 70 packet contains a filename encrypted with a Filename Encryption
Key (FNEK). This patch implements functions for writing and parsing tag
70 packets. This patch also adds definitions and extends structures to
support filename encryption.Signed-off-by: Michael Halcrow
Cc: Dustin Kirkland
Cc: Eric Sandeen
Cc: Tyler Hicks
Cc: David Kleikamp
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
31 Oct, 2008
1 commit
-
When ecryptfs allocates space to write crypto headers into, before copying
it out to file headers or to xattrs, it looks at the value of
crypt_stat->num_header_bytes_at_front to determine how much space it
needs. This is also used as the file offset to the actual encrypted data,
so for xattr-stored crypto info, the value was zero.So, we kzalloc'd 0 bytes, and then ran off to write to that memory.
(Which returned as ZERO_SIZE_PTR, so we explode quickly).The right answer is to always allocate a page to write into; the current
code won't ever write more than that (this is enforced by the
(PAGE_CACHE_SIZE - offset) length in the call to
ecryptfs_generate_key_packet_set). To be explicit about this, we now send
in a "max" parameter, rather than magically using PAGE_CACHE_SIZE there.Also, since the pointer we pass down the callchain eventually gets the
virt_to_page() treatment, we should be using a alloc_page variant, not
kzalloc (see also 7fcba054373d5dfc43d26e243a5c9b92069972ee)Signed-off-by: Eric Sandeen
Acked-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
29 Jul, 2008
1 commit
-
With SLUB debugging turned on in 2.6.26, I was getting memory corruption
when testing eCryptfs. The root cause turned out to be that eCryptfs was
doing kmalloc(PAGE_CACHE_SIZE); virt_to_page() and treating that as a nice
page-aligned chunk of memory. But at least with SLUB debugging on, this
is not always true, and the page we get from virt_to_page does not
necessarily match the PAGE_CACHE_SIZE worth of memory we got from kmalloc.My simple testcase was 2 loops doing "rm -f fileX; cp /tmp/fileX ." for 2
different multi-megabyte files. With this change I no longer see the
corruption.Signed-off-by: Eric Sandeen
Acked-by: Michael Halcrow
Acked-by: Rik van Riel
Cc: [2.6.25.x, 2.6.26.x]
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
25 Jul, 2008
1 commit
-
Fixes the following sparse warnings:
fs/ecryptfs/crypto.c:1036:8: warning: cast to restricted __be32
fs/ecryptfs/crypto.c:1038:8: warning: cast to restricted __be32
fs/ecryptfs/crypto.c:1077:10: warning: cast to restricted __be32
fs/ecryptfs/crypto.c:1103:6: warning: incorrect type in assignment (different base types)
fs/ecryptfs/crypto.c:1105:6: warning: incorrect type in assignment (different base types)
fs/ecryptfs/crypto.c:1124:8: warning: incorrect type in assignment (different base types)
fs/ecryptfs/crypto.c:1241:21: warning: incorrect type in assignment (different base types)
fs/ecryptfs/crypto.c:1244:30: warning: incorrect type in assignment (different base types)
fs/ecryptfs/crypto.c:1414:23: warning: cast to restricted __be32
fs/ecryptfs/crypto.c:1417:32: warning: cast to restricted __be16Signed-off-by: Harvey Harrison
Cc: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
25 May, 2008
1 commit
-
Cc: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
29 Apr, 2008
2 commits
-
__FUNCTION__ is gcc-specific, use __func__
Signed-off-by: Harvey Harrison
Cc: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Remove the no longer used ecryptfs_header_cache_0.
Signed-off-by: Adrian Bunk
Cc: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
07 Feb, 2008
6 commits
-
Jeff Moyer pointed out that a mount; umount loop of ecryptfs, with the same
cipher & other mount options, created a new ecryptfs_key_tfm_cache item
each time, and the cache could grow quite large this way.Looking at this with mhalcrow, we saw that ecryptfs_parse_options()
unconditionally called ecryptfs_add_new_key_tfm(), which is what was adding
these items.Refactor ecryptfs_get_tfm_and_mutex_for_cipher_name() to create a new
helper function, ecryptfs_tfm_exists(), which checks for the cipher on the
cached key_tfm_list, and sets a pointer to it if it exists. This can then
be called from ecryptfs_parse_options(), and new key_tfm's can be added
only when a cached one is not found.With list locking changes suggested by akpm.
Signed-off-by: Eric Sandeen
Cc: Michael Halcrow
Cc: Jeff Moyer
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Only the lower byte of cipher_code is ever used, so it makes sense
for its type to be u8.Signed-off-by: Trevor Highland
Cc: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The printk statements that result when the user does not have the
proper key available could use some refining.Signed-off-by: Mike Halcrow
Cc: Mike Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
There is no need to keep re-setting the same key for any given eCryptfs inode.
This patch optimizes the use of the crypto API and helps performance a bit.Signed-off-by: Trevor Highland
Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Remove internal references to header extents; just keep track of header bytes
instead. Headers can easily span multiple pages with the recent persistent
file changes.Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
- make the following needlessly global code static:
- crypto.c:ecryptfs_lower_offset_for_extent()
- crypto.c:key_tfm_list
- crypto.c:key_tfm_list_mutex
- inode.c:ecryptfs_getxattr()
- main.c:ecryptfs_init_persistent_file()- remove the no longer used mmap.c:ecryptfs_lower_page_cache
- #if 0 the unused read_write.c:ecryptfs_read()
Signed-off-by: Adrian Bunk
Cc: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
24 Dec, 2007
2 commits
-
Thanks to Josef Bacik for finding these.
A couple of ecryptfs error paths don't properly unlock things they locked.
Signed-off-by: Eric Sandeen
Cc: Josef Bacik
Cc: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Passing a cipher name > 32 chars on mount results in an overflow when the
cipher name is printed, because the last character in the struct
ecryptfs_key_tfm's cipher_name string was never zeroed.Signed-off-by: Eric Sandeen
Acked-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
06 Nov, 2007
2 commits
-
Release the crypt_stat hash mutex on allocation error. Check for error
conditions when doing crypto hash calls.Signed-off-by: Michael Halcrow
Reported-by: Kazuki Ohta
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The extent_offset is getting incremented twice per loop iteration through any
given page. It should only be getting incremented once. This bug should only
impact hosts with >4K page sizes.Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
27 Oct, 2007
1 commit
-
This patch fixes the errors made in the users of the crypto layer during
the sg_init_table conversion. It also adds a few conversions that were
missing altogether.Signed-off-by: Herbert Xu
Signed-off-by: David S. Miller
24 Oct, 2007
1 commit
-
Most drivers need to set length and offset as well, so may as well fold
those three lines into one.Add sg_assign_page() for those two locations that only needed to set
the page, where the offset/length is set outside of the function context.Signed-off-by: Jens Axboe
23 Oct, 2007
1 commit
-
Signed-off-by: Jens Axboe
17 Oct, 2007
9 commits
-
The functions that eventually call down to ecryptfs_read_lower(),
ecryptfs_decrypt_page(), and ecryptfs_copy_up_encrypted_with_header()
should have the responsibility of managing the page Uptodate
status. This patch gets rid of some of the ugliness that resulted from
trying to push some of the page flag setting too far down the stack.Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Replace some magic numbers with sizeof() equivalents.
Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
The switch to read_write.c routines and the persistent file make a number of
functions unnecessary. This patch removes them.Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Update data types and add casts in order to avoid potential overflow
issues.Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Rather than open a new lower file for every eCryptfs file that is opened,
truncated, or setattr'd, instead use the existing lower persistent file for
the eCryptfs inode. Change truncate to use read_write.c functions. Change
ecryptfs_getxattr() to use the common ecryptfs_getxattr_lower() function.Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Update the metadata read/write functions and grow_file() to use the
read_write.c routines. Do not open another lower file; use the persistent
lower file instead. Provide a separate function for
crypto.c::ecryptfs_read_xattr_region() to get to the lower xattr without
having to go through the eCryptfs getxattr.Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Replace page encryption and decryption routines and inode size write routine
with versions that utilize the read_write.c functions.Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Remove assignments in if-statements.
Signed-off-by: Michael Halcrow
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
There is no point to keeping a separate header_extent_size and an extent_size.
The total size of the header can always be represented as some multiple of
the regular data extent size.[randy.dunlap@oracle.com: ecryptfs: fix printk format warning]
Signed-off-by: Michael Halcrow
Signed-off-by: Randy Dunlap
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds