| Age | Commit message (Collapse) | Author |
|---|
|
Update https://github.com/google/fscrypt/issues/220
|
|
Update https://github.com/google/fscrypt/issues/220
|
|
- Mention that a v5.4+ kernel is recommended.
- Mention that policy_version defaults to 1 when unset.
- Emphasize that v2 policies are the recommended solution to the key
visibility problems, and add some more information.
|
|
Since on new kernels v1 encryption policies are deprecated in favor of
v2, update the examples to show v2. This mostly just consists of
updating the output, as the commands are essentially the same with one
notable difference in 'fscrypt lock'.
|
|
There's no real need to allow users to choose the key description prefix
(a.k.a. the "service"), since on ext4 and f2fs we can just use "ext4"
and "f2fs" for compatibility with all kernels both old and new, and on
other filesystems we can just use "fscrypt". So, let's do that.
Since this removes the point of the "--legacy" option to 'fscrypt setup'
and the "compatibility" field in /etc/fscrypt.conf, remove those too.
Specifically, we start ignoring the "compatibility" in existing config
files and not writing it to new ones. The corresponding protobuf field
number and name are reserved. We stop accepting the "--legacy" option
at all, although since it was default true and there was no real reason
for anyone to change it to false, probably no one will notice. If
anyone does, they should just stop specifying the option.
Note that this change only affects user keyrings and thus only affects
v1 encryption policies, which are deprecated in favor of v2 anyway.
|
|
|
|
When 'fscrypt setup' sees that /etc/fscrypt.conf doesn't exist, don't
ask for confirmation before creating it. Just do it. This is the
normal use, and there's not a good reason to ask the user to confirm it.
|
|
Resolves https://github.com/google/fscrypt/issues/181
|
|
Document the new /etc/fscrypt.conf settings for the filesystem keyring
and v2 encryption policies, and add a new subsection for troubleshooting
key access problems.
|
|
Implement adding/removing v2 encryption policy keys to/from the kernel.
The kernel requires that the new ioctls FS_IOC_ADD_ENCRYPTION_KEY and
FS_IOC_REMOVE_ENCRYPTION_KEY be used for this. Root is not required.
However, non-root support brings an extra complication: the kernel keeps
track of which users have called FS_IOC_ADD_ENCRYPTION_KEY for the same
key. FS_IOC_REMOVE_ENCRYPTION_KEY only works as one of these users, and
it only removes the calling user's claim to the key; the key is only
truly removed when the last claim is removed.
Implement the following behavior:
- 'fscrypt unlock' and pam_fscrypt add the key for the user, even if
other user(s) have it added already. This behavior is needed so that
another user can't remove the key out from under the user.
- 'fscrypt lock' and pam_fscrypt remove the key for the user. However,
if the key wasn't truly removed because other users still have it
added, 'fscrypt lock' prints a warning.
- 'fscrypt status' shows whether the directory is unlocked for anyone.
|
|
Linux v5.4 and later supports v2 encryption policies. These have
several advantages over v1 encryption policies:
- Their encryption keys can be added/removed to/from the filesystem by
non-root users, thus gaining the benefits of the filesystem keyring
while also retaining support for non-root use.
- They use a more standard, secure, and flexible key derivation
function. Because of this, some future kernel-level fscrypt features
will be implemented for v2 policies only.
- They prevent a denial-of-service attack where a user could associate
the wrong key with another user's encrypted files.
Prepare the fscrypt tool to support v2 encryption policies by:
- Adding a policy_version field to the EncryptionOptions, i.e. to the
config file and to the policy metadata files.
- Using the kernel-specified algorithm to compute the key descriptor for
v2 policies.
- Handling setting and getting v2 policies.
Actually adding/removing the keys for v2 policies to/from the kernel is
left for the next patch.
|
|
Add support for 'fscrypt lock'. This command "locks" a directory,
undoing 'fscrypt unlock'.
When the filesystem keyring is used, 'fscrypt lock' also detects when a
directory wasn't fully locked due to some files still being in-use. It
can then be run again later to try to finish locking the files.
|
|
|
|
Update the example output in the README to match reality.
Also make a few other updates to the examples to take into account that
'fscrypt purge' now drops caches by default, and that the root
filesystem doesn't need to support encryption if the encrypted
directories are being created on a different filesystem.
Resolves https://github.com/google/fscrypt/issues/62
|
|
For some time now, fscrypt actually does re-wrap a user's login
protector when their login passphrase changes, provided that the PAM
configuration is correct. Remove the obsolete paragraph.
Update https://github.com/google/fscrypt/issues/51
|
|
Saying "Your data can be protected with one of the following sources" is
ambiguous because it could be interpreted to mean that an encrypted
directory can only have one type of protector. In fact, an encrypted
directory can have multiple protectors, and they can be of any type.
Update https://github.com/google/fscrypt/issues/164
|
|
As the Go community transitions to using the modules ecosystem,
we want to only support one way of managing dependencies.
So this change moves to only using Go modules for dependency management.
This means that our effective minimum Go version increases to Go 1.11.
To account for this, we also update:
- the documentation
- Makefile
- CI scripts
|
|
Make the global setup command also create the metadata directory at
/.fscrypt, since that's where login protectors are placed, even when the
actual encrypted directories are on a different filesystem.
Resolves https://github.com/google/fscrypt/issues/129
|
|
These were found by a combination of manual review and a custom script
that checks for common errors.
Also removed an outdated sentence from the comment for setupBefore().
|
|
Resolves https://github.com/google/fscrypt/issues/124
|
|
Resolves https://github.com/google/fscrypt/issues/117
Resolves https://github.com/google/fscrypt/issues/127
|
|
Resolves https://github.com/google/fscrypt/issues/58
|
|
|
|
|
|
* Remove spelling mistakes in the repository
* Add travis script to check for typos.
* Add command to Makefile to check for typos.
* Fixes #71
|
|
|
|
PR #85 failed to update the documentation. This is now fixed with some
additional cleanup.
|
|
Now that Argon2 is simply and implementation detail of the `crypto`
package, and no a build dependancy, we don't need it in Travis or in the
documenation for building fscrypt.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The version badge was broken. This fixes it and inlines the version in the top line.
|
|
|
|
|
|
|
|
|
|
|
|
Some of the documentation was misspelled or incorrectly formatted.
|
|
This commit changes all the internal import paths from `fscrypt/foo` to
`github.com/google/fscrypt/foo` so that it can be built once we release
externaly. The documentation in README.md is updated accordingly.
Also, the README has a note noting that we do not make any guarantees
about project stability before 1.0 (when it ships with Ubuntu).
Change-Id: I6ba86e442c74057c8a06ba32a42e17f94833e280
|
|
This commit updates the README and Makefile to get them ready for
external release. This includes adding some common pitfalls, including
example usage, and allowing for tarball creation.
Change-Id: I442338c7aff613a14bae449dbf091bfcaf73ed9d
|
|
This commit adds in the fscrypt/pam package. This package will hold all
functionality related to Linux Pluggable Authentication Modules (PAM).
Right now this package uses cgo to mock a PAM conversation, allowing the
function to check if a provided passphrase actually belongs to a user.
Due to the nature of cgo callbacks, global state of the key to check is
necessary for this function. This commit also addresses some issues
about building the cgo components. Now, only the minimal linking flags
are included in the go files. Additional linker flags may now be
necessary to build a static binary of fscrypt. This is addressed in the
Makefile and README.
Finally, this commit fixes a bug where the tests would not run correctly
due to shared global state on the testing filesystem. Fixed, by having
all the tests run sequentially.
Change-Id: Ia43636801da984b505d2f43dd14127b7cfbf2c48
|
|
This commit moves most of the documentation about contributing to
fscrypt into CONTRIBUTING.md and updates the legal disclaimer.
It also updates the README.md to include all of fscrypt's planned
functionality and dependencies. Finally, the makefile is updated to
include more documentation, versioning support, and a different location
for the output file.
Change-Id: Ib7be98d41bc06dd12b02e42addf06e12a940235a
|
|
This commit adds in the PassphraseHash function which hashes the
provided passphrase (in key form) using Argon2id. This cost parameters
for Argon2id and that salt are both fed into the function. It also
includes tests and benchmarks for the passphrase hashing.
Change-Id: I060db3e71213c756d45ce5603a0a59d3d7a1e609
|
