| Age | Commit message (Collapse) | Author |
|---|
|
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 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.
|
|
Make it clear that this refers to a type of filesystem such as "ext4",
rather than to a specific filesystem instance.
|
|
Show the encryption options when running 'fscrypt status' on a
directory. E.g.:
Policy: 490515286453d3f7
Options: padding:32 contents:Adiantum filenames:Adiantum
Unlocked: Yes
|
|
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().
|
|
The --user flag can now be used to have the targe user (the one whose
keyring and password will be used in fscrypt) be different than the
calling user. Very usefull for things like
sudo fscrypt purge /media/joerichey/usb --user=joerichey
which will now have privileges to drop caches, but will properly clear
the keys from the user's keyring.
|
|
Now that we can distinguish between lacking encryption support and
lacking fscrypt metadata, "fscrypt status" can now display this
additional information.
|
|
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 adds in the status command, which has 2 functions, allowing
the user to query the state of the entire system or a specific
filesystem.
This commit also adds in the purge command to remove all policy keys
corresponding to a filesystem. This (along with getting the unlock
status for the status commands) uses additional keyctl functionality in
the crypto and actions packages.
Change-Id: Ic8e097b335c044c0b91973eff19753f363f4525d
|
