[Documentation] policy_version 2 is not used automatically

[Redsandro]

I updated a machine to Ubuntu 20.04, manually compiled fscrypt version v0.2.9-2-g5e85ae0, and removed policy_version from /etc/fscrypt.conf so that it not looks something like this:

{
	"source": "custom_passphrase",
	"hash_costs": {
		"time": "1",
		"memory": "4465726",
		"parallelism": "8"
	},
	"compatibility": "legacy",
	"options": {
		"padding": "32",
		"contents": "AES_256_XTS",
		"filenames": "AES_256_CTS"
	}
}

I've created a new home and encrypted the directory. From what I understand, with the default 5.4.0 kernel, fscrypt should automatically use policy_version:2. However, after rsyncing all files over, reboot and login, it still shows policy_version:1:

$ fscrypt status /home/redsandro
"/home/redsandro" is encrypted with fscrypt.

Policy:   1234567812345678
Options:  padding:32 contents:AES_256_XTS filenames:AES_256_CTS policy_version:1 
Unlocked: Yes

Protected with 2 protectors:
PROTECTOR         LINKED   DESCRIPTION
1234123412341234  Yes (/)  login protector for redsandro
2345234523452345  No       custom protector "Recovery passphrase for redsandro-new"

What should I do (have done) differently?

• Does the policy version affect the directory or the protector?
• Could it be that the pre-existing protector (from Ubuntu 18.04), that was automatically re-used, enforces the v1?
• Can v1 and v2 co-exist so I can rsync from my unlocked v1 home to the new v2 home?

[ebiggers]

policy_version defaults to 1 if unset, to maintain compatibility with existing configuration files. See https://github.com/google/fscrypt#configuration-file.

It's the fscrypt setup command, which creates /etc/fscrypt.conf, that will set "policy_version": "2" for you. See https://github.com/google/fscrypt#cant-log-in-with-ssh-even-when-users-encrypted-home-directory-is-unlocked.

It sounds like you already have an existing configuration file. You'll just need to add "policy_version": "2" to it yourself.

The policy version is for policies, not protectors. Protectors don't care about whether they are protecting v1 policies, v2 policies, or a combination of the two.

[Redsandro]

So after I do that, is it necessary to recreate my home dir with a new policy, or can I add a new policy to the same directory? *

When I encrypt a new empty directory, it asks whether I should make a new protector:

$ fscrypt encrypt redsandro-v2/
Should we create a new protector? [y/N]

But I believe this is what I did last time. I need it to make a new policy.

---

-edit-

*) The answer is in the documentation you quoted:

This only affects new directories. If you want to upgrade an existing encrypted directory to use a v2 policy, you'll need to re-create it by using fscrypt encrypt to encrypt a new empty directory, copying your files into it, and replacing the original directory with it.

---

-edit-

[ERROR] fscrypt encrypt: user "redsandro" already has a login protector

I am not sure how to proceed. Does the pre-existing protector for this user automatically get a new policy?

---

-edit-

$ fscrypt encrypt redsandro-v2/
Should we create a new protector? [y/N] 
The available protectors are: 
0 - custom protector "Recovery passphrase for redsandro-new"
1 - login protector for sander (linked protector on "/")
Enter the number of protector to use: 1
Enter login passphrase for redsandro: 
Protector is on a different filesystem! Generate a recovery passphrase (recommended)? [Y/n] y
See "redsandro-v2/fscrypt_recovery_readme.txt" for important recovery instructions!
"redsandro-v2/" is now encrypted, unlocked, and ready for use.

$ fscrypt status redsandro-v2/
"redsandro-v2/" is encrypted with fscrypt.

Policy:   12345678123456781234567812345678
Options:  padding:32 contents:AES_256_XTS filenames:AES_256_CTS policy_version:2 
Unlocked: Yes

Protected with 2 protectors:
PROTECTOR         LINKED   DESCRIPTION
1234123412341234  Yes (/)  login protector for redsandro
2345234523452345  No       custom protector "Recovery passphrase for redsandro-v2"
$ 

I believe it worked!

I'll leave my edits/updates here, in case it will help somebody else.

I might need to do some cleanup and remove the old protectors and old policy.

[josephlr]

@Redsandro what you did in your final edit is correct, I'll track this as (yet another) doc bug to clarify the "upgrade" senario to include examples.

You shouldn't need to create any new protectors (other than recover protectors) when going from v1 to v2. If you inadvertently created a protector, it will show up when you get the "The available protectors are:" dialog.

To remove a completely unused protector you can run fscrypt metadata destroy --protector=MOUNTPOINT:ID.

If you have a policy and the directory has been deleted, you can run fscrypt metadata destroy --policy=MOUNTPOINT:ID

You can get the ids/status of policies and protectors by running fscrypt status MOUNTPOINT. Note that keeping these policies/protectors around don't do much harm. I recommend first removing policies that no longer apply to any directory and then removing protectors that no longer protect any policy.

[Redsandro]

I have removed the discussion below to new separate issues. We can rewind this issue to:

I'll track this as (yet another) doc bug to clarify the "upgrade" senario to include examples.

Original comment below:

---

@josephlr thanks for the directions.

I have destroyed one policy and one protector which I was quite sure I didn't need, but it still felt like a gamble and I made a backup beforehand.

There are a lot of encrypted directories scattered over 4 mountpoints. I'm quite sure I have only two policies and three protectors in use: One v1 policy with the login protector and the recovery protector (used for most directories), and one v2 policy with the same login protector but a new auto-generated recovery protector (used for the newly created home).

However I still have four of each, but it's been too long so I keep them just in case. I have three recommendations:

1. It would be helpful if fscrypt could do a recursive scan and list what protectors/policies are unused within current mountpoints so the user feels more at ease deleting them. -> [Feature] Recursive scan for unused protectors and policies #253
2. Encrypting a new directory with a new v2 policy re-uses the login protector. However, it does not re-use the recovery protector, but creates a new one (Y/n). User ends up with multiple directories with the same login protector but different recovery protectors. It would be simpler if there is a way to detect/offer to use existing recovery protectors. -> [Feature] Automatically re-use recovery protector when re-using login protector #252
3. ⚠️ It's really easy to remove a protector. Can this be abused by ransomware? Should we enforce a sudo roundtrip for that, so that if user steps into a malicious buffer overflow or tricked into running something, it will be stopped at the administrator elevation prompt? -> [Security] It's really easy to remove a protector. Can this be abused by ransomware? #251

[Maryse47]

It's really easy to remove a protector. Can this be abused by ransomware? Should we enforce a sudo roundtrip for that, so that if user steps into a malicious buffer overflow or tricked into running something, it will be stopped at the administrator elevation prompt?

It's same as easy to remove any other file or even all files. sudo is not a boundary if user account has access to it and attacker has arbitrary code exec. They can just run something in a loop while waiting for your credentials.

[Redsandro]

@Maryse47 I've moved this thread to a new issue: #251

Please disregard my last post, it's been moved to separate issues. This issue can be rewound to:

I'll track this as (yet another) doc bug to clarify the "upgrade" senario to include examples.