From 8cd1b3ba2e7a12cd68e2dfd0cbb5ec09ff92783b Mon Sep 17 00:00:00 2001 From: Eric Biggers Date: Wed, 27 Nov 2019 12:04:13 -0800 Subject: Automatically generate recovery passphrase when useful 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 --- cmd/fscrypt/commands.go | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) (limited to 'cmd/fscrypt') diff --git a/cmd/fscrypt/commands.go b/cmd/fscrypt/commands.go index 41009b0..65e0f45 100644 --- a/cmd/fscrypt/commands.go +++ b/cmd/fscrypt/commands.go @@ -24,11 +24,13 @@ import ( "fmt" "log" "os" + "path/filepath" "github.com/pkg/errors" "github.com/urfave/cli" "github.com/google/fscrypt/actions" + "github.com/google/fscrypt/crypto" "github.com/google/fscrypt/filesystem" "github.com/google/fscrypt/keyring" "github.com/google/fscrypt/metadata" @@ -188,6 +190,7 @@ func encryptPath(path string) (err error) { } var policy *actions.Policy + var recoveryPassphrase *crypto.Key if policyFlag.Value != "" { log.Printf("getting policy for %q", path) @@ -227,6 +230,19 @@ func encryptPath(path string) (err error) { if policy, err = actions.CreatePolicy(ctx, protector); err != nil { return } + // Automatically generate a recovery passphrase if the protector + // is on a different filesystem from the policy. In practice, + // this happens for login passphrase-protected directories that + // aren't on the root filesystem, since login protectors are + // always stored on the root filesystem. + if ctx.Mount != protector.Context.Mount { + fmt.Printf("Generating recovery passphrase because protector is on a different filesystem.\n") + if recoveryPassphrase, _, err = actions.AddRecoveryPassphrase( + policy, filepath.Base(path)); err != nil { + return + } + defer recoveryPassphrase.Wipe() + } } // Successfully created policy should be reverted on failure. defer func() { @@ -255,6 +271,16 @@ func encryptPath(path string) (err error) { // EACCES at this point indicates ownership issues. err = errors.Wrap(ErrBadOwners, path) } + if err != nil { + return + } + if recoveryPassphrase != nil { + recoveryFile := filepath.Join(path, "fscrypt_recovery_readme.txt") + if err = actions.WriteRecoveryInstructions(recoveryPassphrase, recoveryFile); err != nil { + return + } + fmt.Printf("See %q for important recovery instructions!\n", recoveryFile) + } return } -- cgit v1.2.3