Go tool for managing Linux filesystem encryption https://git.hodgden.net/cgit.cgi/fscrypt.git/atom?h=v0.2.6 2020-01-05T18:02:13Z 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:6ffc9457945a9484d2757cc4b01de35426502d0a Linux v5.4 and later allows fscrypt keys to be added/removed directly to/from the filesystem via the new ioctls FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY. Among other benefits, these fix the key visibility problems that many users have been running into, where system services and containers can't access encrypted files. Allow the user to opt-in to using these new ioctls for their existing encrypted directories by setting in their /etc/fscrypt.conf: "use_fs_keyring_for_v1_policies": true Note that it can't really be on by default, since for v1 policies the ioctls require root, whereas user keyrings don't. I.e., setting this to true means that users will need to use 'sudo fscrypt unlock', not 'fscrypt unlock'. v2 policies won't have this restriction. 2020-01-05T18:02:13Z Eric Biggers ebiggers@google.com 2019-12-16T03:31:39Z urn:sha1:462d166d5355d33a05271d24de4d52f30dd62f67 In preparation for introducing support for the new filesystem-level keyrings, move the existing user keyring management code from security/keyring.go and crypto/crypto.go into a new package, 'keyring'. This package provides functions AddEncryptionKey, RemoveEncryptionKey, and GetEncryptionKeyStatus which delegate to either the filesystem keyring (added by a later patch) or to the user keyring. This provides a common interface to both types of keyrings, to the extent possible. 2019-11-27T19:40:47Z Eric Biggers ebiggers@google.com 2019-11-27T19:40:47Z urn:sha1:03d3a29b70c85f083adf3c12cba60c0374f06d3e Refer to the target User as 'targetUser' rather than simply 'target'. This will help avoid confusion when we add support for the filesystem keyring, since then the Mount will also be a "target". 2019-11-27T19:28:14Z Eric Biggers ebiggers@google.com 2019-11-27T19:28:14Z urn:sha1:82d01438a66212ce802721397a62c18a0b71b7ea Use the new name for fscrypt constants and structures which have been given a new name. Also use the named constant for the DIRECT_KEY fscrypt policy flag. No change in behavior. This is just preparing for future work. 2019-10-29T07:04:39Z Eric Biggers ebiggers@google.com 2019-10-29T07:04:39Z urn:sha1:249259376da98d8e10e6876c80ff3905e9756bdc Make it clear that this refers to a type of filesystem such as "ext4", rather than to a specific filesystem instance. 2019-09-09T02:46:59Z ebiggers ebiggers@google.com 2019-09-09T02:46:59Z urn:sha1:6445dad7d66fa6a1867090fcd9602c98863649f6 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(). 2017-08-31T01:00:04Z Joe Richey joerichey@google.com 2017-08-31T01:00:04Z urn:sha1:dad0a047cefc79cbe664afc07d69db6b8bf123bd This user is used with policies to interface with the keryings and with protectors to indicate which user's login passphrase should be used to protectors of type pam_passphrase. 2017-08-18T05:49:44Z Joe Richey joerichey@google.com joerichey@google.com 2017-08-16T01:11:29Z urn:sha1:151e8965fa3a9c8f65e316430f9df0fa763fb02d 2017-07-17T19:15:20Z Joe Richey joerichey@google.com joerichey@google.com 2017-07-17T19:15:20Z urn:sha1:c5e23466e7b9f814fd5ecc3a5d965bd1f1dd2987 In addition to using callbacks, unlocked Protectors can now directly unlock a policy. The error codes are updated to make more sense.