Go tool for managing Linux filesystem encryption https://git.hodgden.net/cgit.cgi/fscrypt.git/atom?h=v0.2.6 2020-01-28T09:57:46Z 2020-01-28T09:57:46Z Eric Biggers ebiggers@google.com 2020-01-28T09:57:46Z urn:sha1:2c57ab18375a8d0b4df9c4b6d9f3692d14edfee7 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. 2020-01-23T21:46:18Z ebiggers ebiggers@google.com 2020-01-23T21:46:18Z urn:sha1:45c27d59ee40f3945837ea827f29f6896414157f Resolves https://github.com/google/fscrypt/issues/181 2020-01-05T18:03:54Z Eric Biggers ebiggers@google.com 2019-12-16T03:31:39Z urn:sha1:fe2939cc7e50f4c6025253efdf7380c04fac9ae1 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. 2020-01-05T18:02:13Z Eric Biggers ebiggers@google.com 2019-12-16T03:31:39Z urn:sha1:42e0dfe85ec7a75a2fa30c417d57eae60b5a881d 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. 2020-01-05T18:02:13Z Eric Biggers ebiggers@google.com 2019-12-16T03:31:39Z urn:sha1:2b25de6d445faefc28629603dd754aec9f744e60 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. 2020-01-05T18:02:13Z Eric Biggers ebiggers@google.com 2019-12-16T03:31:39Z urn:sha1:9003a0331a112e8901fae8279f4897a825ee8069 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. 2020-01-05T18:00:33Z Eric Biggers ebiggers@google.com 2020-01-05T17:59:37Z urn:sha1:80654f23ebfd552277ed217a2c5e1d0bb1374189 2019-11-28T18:26:31Z Eric Biggers ebiggers@google.com 2019-11-28T18:06:32Z urn:sha1:6821d90d7c449b63d602c272d5ffa19243a7c517 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 2019-11-28T05:04:37Z Eric Biggers ebiggers@google.com 2019-11-28T05:00:32Z urn:sha1:87e9540d42249bfafc2e26785ba96739b2b87fdd 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 2019-11-27T19:20:19Z Eric Biggers ebiggers@google.com 2019-11-27T19:20:19Z urn:sha1:10bbfcbfe125e9c9568031328e372c01ff144fc9 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