| Age | Commit message (Collapse) | Author |
|---|
|
World-writable directories are not appropriate for some systems, so
offer a choice of single-user-writable and world-writable modes, with
single-user-writable being the default. Add a new documentation section
to help users decide which one to use.
|
|
Make remove-protector-from-policy work even if the protector cannot be
loaded (for example, due to having been deleted already).
Fixes https://github.com/google/fscrypt/issues/258
Fixes https://github.com/google/fscrypt/issues/272
|
|
As per the feedback at https://github.com/google/fscrypt/issues/115
where users didn't understand that the recovery passphrase is important,
restore the original behavior where recovery passphrase generation
happens automatically without a prompt. This applies to the case where
'fscrypt encrypt' is using a login protector on a non-root filesystem.
However, leave the --no-recovery option so that the recovery passphrase
can still be disabled if the user really wants to. Also, clarify the
information provided about the recovery passphrase.
Update https://github.com/google/fscrypt/issues/115
|
|
In Linux 5.15, the no-key name format is changing again; see
https://git.kernel.org/linus/ba47b515f5940603. isPossibleNoKeyName()
sometimes doesn't recognize the new no-key names. Update it accordingly
to recognize all possible no-key names.
Note: isPossibleNoKeyName() is only used as a heuristic to check whether
a v1-encrypted directory is incompletely locked or not. Therefore, it's
not too important whether it works. However, this change is needed for
cli-tests/t_v1_policy to pass.
|
|
Fix word mismatch in usage and description of metadata create policy
command.
|
|
On an "incompletely locked" directory, isDirUnlockedHeuristic() is
supposed to return true, but on Linux v5.10-rc1 and later it returns
false since now creating a subdirectory fails rather than succeeds.
This change was intentional, so make isDirUnlockedHeuristic() apply a
second heuristic too: also return true if any filenames in the directory
don't appear to be valid no-key names.
This fixes cli-tests/t_v1_encrypt on Linux v5.10-rc1 and later.
|
|
|
|
In checkEncryptable(), check whether the directory is already encrypted
before checking whether it's empty.
Also improve the error message for when a directory is nonempty.
Finally, translate keyring.ErrKeyAddedByOtherUsers and
keyring.ErrKeyFilesOpen into errors which include the directory.
|
|
Introduce filesystem.ErrEncryptionNotEnabled and
filesystem.ErrEncryptionNotSupported which include the Mount as context,
and translate the corresponding metadata/ errors into them. Then make
these errors show much better suggestions.
Also replace lots of other filesystem/ errors with either custom types
or with unnamed one-off errors that include more context. Fix backwards
wrapping in lots of cases.
Finally, don't include the mountpoint in places where it's not useful,
like OS-level errors that already include the path.
|
|
ErrBadOwners:
Rename to ErrDirectoryNotOwned for clarity, move it from
cmd/fscrypt/ to metadata/ where it better belongs, and improve
the message.
ErrEncrypted:
Rename to ErrAlreadyEncrypted for clarity, and include the path.
ErrNotEncrypted:
Include the path.
ErrBadEncryptionOptions:
Include the path and bad options.
ErrEncryptionNotSupported:
ErrEncryptionNotEnabled:
Don't wrap with "get encryption policy %s", in preparation for
wrapping these with filesystem-level context instead.
Also avoid mixing together the error handling for the "get policy" and
"set policy" ioctls. Make it very clear how we're handling the errors
from each ioctl.
|
|
'fscrypt lock' on a v1-encrypted directory doesn't warn about in-use
files, as the kernel doesn't provide a way to easily detect it.
Instead, implement a heuristic where we check whether a subdirectory can
be created. If yes, then the directory must not be fully locked.
Make both 'fscrypt lock' and 'fscrypt status' use this heuristic.
Resolves https://github.com/google/fscrypt/issues/215
|
|
Allow overriding the mountpoint where login protectors are stored by
setting the FSCRYPT_ROOT_MNT environmental variable. The CLI tests need
this to avoid touching the real "/".
|
|
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.
|
|
While it's important to generate a recovery passphrase in the linked
protector case to avoid data loss if the system is reinstalled, some
people really don't want it (even though it can be safely ignored as it
almost certainly has far more entropy than the login passphrase).
As a compromise, prompt for y/n before generating it, with default y.
Also, to allow disabling the recovery passphrase during noninteractive
use, add a --no-recovery command-line option.
Update https://github.com/google/fscrypt/issues/186
|
|
Move the deferred locking and deletion of the policy on failure to the
correct places, so that it's done in all failure cases, including in the
case where adding the recovery protector fails.
Also make the recovery protector be locked and deleted on failure.
Finally, put all the code to do deferred deprovisioning of the policy in
the same place: right after it's provisioned.
|
|
If a user re-installs their system (or otherwise loses the /.fscrypt
directory on the root filesystem) they also lose access to any login
passphrase-protected directories on other filesystems, unless additional
protectors were manually added. This can be unexpected, as it may be
expected that the old login passphrase would still work.
We can't really fix this by storing a login protector on every
filesystem because:
- If a user were to have N login protectors, it would take them N times
longer to log in, as every login protector would need to be unlocked.
- If a user were to change their login passphrase while any external
volumes were unmounted, login protectors would get out of sync.
- It's preferable that an external volume isn't unlockable by itself
using only a login passphrase, as login passphrases are often weak.
Instead, generate a recovery passphrase when creating a login
passphrase-protected directory on a non-root filesystem.
The recovery passphrase is added as a custom_passphrase protector, thus
giving the policy two protectors: one pam_passphrase and one
custom_passphrase. Then this passphrase is written to a file in the new
encrypted directory. Writing the passphrase to a file here is okay
since it's encrypted, but it's obviously useless by itself; it's up to
the user to store this passphrase somewhere else if they need it.
Use a recovery passphrase instead of a "recovery code" that encodes the
policy key directly because a passphrase is more user-friendly: it can
safely be made much shorter than a key, and it works just like any other
fscrypt protector. Also, it's not as critical to allow recovery when
the .fscrypt directory on the *same* filesystem is deleted.
Resolves https://github.com/google/fscrypt/issues/164
|
|
Allow root to provide the --all-users option to 'fscrypt lock' to force
an encryption key to be removed from the filesystem (i.e., force an
encrypted directory to be locked), even if other users have added it.
To implement this option, we just need to use the
FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS ioctl rather than
FS_IOC_REMOVE_ENCRYPTION_KEY.
In theory this option could be implemented for the user keyrings case
too, but it would be difficult and the user keyrings are being
deprecated for fscrypt, so don't bother.
|
|
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.
|
|
Don't force the user to provide a --user argument when running fscrypt
as root if they're doing something where the TargetUser isn't actually
needed, such as provisioning/deprovisioning a v1 encryption policy
to/from the filesystem keyring, or creating a non-login protector.
Also don't set up the user keyring (or check for it being set up) if it
won't actually be used.
Finally, if we'll be provisioning/deprovisioning a v1 encryption policy
to/from the filesystem keyring, make sure the command is running as
root, since the kernel requires this.
|
|
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.
|
|
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".
|
|
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/132
|
|
Running "go vet -shadow ./..." finds all places where a variable might
be incorrectly or unnecessarily shadowed. This fixes some of them.
|
|
|
|
We should always log the descriptor not the entire policy structure.
|
|
Chaning the --user flag to (optionally) check for a proper keyring setup
allows us to fail early in cases where we need a working keyring.
|
|
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.
|
|
|
|
|
|
Almost all actions only need to to check that the fscrypt metadata
exists (this is handled by the Mount methods). Only "fscrypt encrypt"
need to be sure the filesystem also supports encryption, so this check
is added.
|
|
Protectors are only reverted if they were created, and Policies are only
depovisioned on failure.
|
|
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 "fscrypt metadata add-protector-to-policy" and
the "fscrypt metadata remove-protector-from-policy" subcommands. These
commands allow for the creating of policies protected by multiple
protectors.
Change-Id: Id7e6c057448d15757c838a82d487a1b9806f585d
|
|
This command adds in the "fscrypt metadata" command. This command allows
advanced users to manipulate the metadata directly instead of just
creating a policy or protector as an option when encrypting a directory.
As some of these methods will require certain flags, error handling for
this case is also added. As the change passphrase method must indicate
when a old vs new password is necessary, additional KeyFuncs are added
which add this indicator.
Change-Id: Ibc92872088fae078df3c0eebd4f0cfcb7252d781
|
|
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
|
|
This commit adds in the framework for adding commands and subcommands to
the fscrypt tool. This commit adds in the "setup", "encrypt", and
"unlock" commands. Additional information can be found by running:
fscrypt <command> --help.
This commit defines how flags are parsed and errors are handled. It also
creates an extensible framework for prompting the user for information.
Change-Id: I159d7f44ee2b2bbc5e072f0802850e082d9a13ce
|
