Error when unlocking filesystem.

[josephlr]

Reported here, reproduced below:

I tested fscrypt with ext4, but I got this error:

root@pc1:/home/hamiltonp/Temp# fscrypt unlock mount/blah/
Enter custom passphrase for protector "test":
fscrypt unlock: permission denied: system error: could not insert key into the keyring

It persisted with password and keyfile method.

[josephlr]

@HamiltonP can you run fscrypt with --debug and post the output here. Also, make sure you are using the current master version.

[josephlr]

@HamiltonP, sorry the flag is actually --verbose.

_## root@pc1:/home/hamiltonp/Temp4# fscrypt unlock blah/dir/ --verbose
2017/08/24 07:29:39 getting mnt_dir: /run/user/1000/gvfs: permission denied
2017/08/24 07:29:39 Reading config from "/etc/fscrypt.conf"
2017/08/24 07:29:39 blah/dir/ is on ext4 filesystem "/home/hamiltonp/Temp4/blah" (/dev/loop5)
2017/08/24 07:29:39 performing sanity checks
2017/08/24 07:29:39 found policy 52591544e6c12567 for "blah/dir/"
2017/08/24 07:29:39 successfully read metadata from "/home/hamiltonp/Temp4/blah/.fscrypt/policies/52591544e6c12567"
2017/08/24 07:29:39 found data for policy 52591544e6c12567 on "/home/hamiltonp/Temp4/blah"
2017/08/24 07:29:39 data from filesystem and path agree
2017/08/24 07:29:39 KeyctlSearch(55672847, logon, ext4:52591544e6c12567) = -1, permission denied
2017/08/24 07:29:39 successfully read metadata from "/home/hamiltonp/Temp4/blah/.fscrypt/protectors/5d48d23aa21dd3cd"
2017/08/24 07:29:39 optionFn(52591544e6c12567)
2017/08/24 07:29:39 selecting from 1 protector
2017/08/24 07:29:39 protector 5d48d23aa21dd3cd selected in callback
2017/08/24 07:29:39 KeyFunc(custom protector "test", false)
Enter custom passphrase for protector "test":
2017/08/24 07:30:18 running passphrase hash for protector 5d48d23aa21dd3cd
2017/08/24 07:30:20 valid wrapping key for protector 5d48d23aa21dd3cd
2017/08/24 07:30:20 unwrapping policy 52591544e6c12567 with protector
2017/08/24 07:30:20 KeyctlAddKey(logon, ext4:52591544e6c12567, , 55672847) = -1, permission denied
fscrypt unlock: permission denied: system error: could not insert key into the keyring

root@pc1:~/Temp# uname -a
Linux pc1 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) x86_64 GNU/Linux_

I tested with loopback and disk devices, passwords and keyfiles, I tested with $ getconf PAGE_SIZE && tune2fs -l /dev/device | grep 'Block size' and $ tune2fs -O encrypt /dev/xx, nothing works.

My system is a Debian Testing/Sid hybrid, everything ok with it.

Also, I tested not only with ext4, but with F2FS too, it got the same error above.

I built your new branch 0.2.0 and I finally did the unlocking of encrypted folder, but...

I can change attributes normally with $ chown -vR user:user /path/mountpoint/encrypted_dir, after unlocking with the new release 0.2.0, but when I try to create a file or a folder, I get this error:

root@pc1:/home/hamiltonp/Desktop# fscrypt status ./1/ --verbose
2017/08/24 14:07:19 getting mnt_dir: /run/user/1000/gvfs: permission denied
2017/08/24 14:07:19 mnt_dir /run/netns/tmp: not a directory
2017/08/24 14:07:19 mnt_dir /run/netns/tmp: not a directory
2017/08/24 14:07:19 Reading config from "/etc/fscrypt.conf"
2017/08/24 14:07:19 found f2fs filesystem "/home/hamiltonp/Desktop/1" (/dev/loop7)
2017/08/24 14:07:19 listing descriptors in "/home/hamiltonp/Desktop/1/.fscrypt/protectors"
2017/08/24 14:07:19 found 1 descriptor(s)
2017/08/24 14:07:19 successfully read metadata from "/home/hamiltonp/Desktop/1/.fscrypt/protectors/42f007083e671014"
2017/08/24 14:07:19 listing descriptors in "/home/hamiltonp/Desktop/1/.fscrypt/policies"
2017/08/24 14:07:19 found 1 descriptor(s)
f2fs filesystem "/home/hamiltonp/Desktop/1" has 1 protector and 1 policy

PROTECTOR LINKED DESCRIPTION
42f007083e671014 No custom protector "1"

2017/08/24 14:07:19 successfully read metadata from "/home/hamiltonp/Desktop/1/.fscrypt/policies/58e3f9758077b6aa"
2017/08/24 14:07:19 got data for 58e3f9758077b6aa from "/home/hamiltonp/Desktop/1"
2017/08/24 14:07:19 KeyctlLink(55672847, -2) =
2017/08/24 14:07:19 KeyctlSearch(55672847, logon, f2fs:58e3f9758077b6aa) = 57726460,
POLICY UNLOCKED PROTECTORS
58e3f9758077b6aa Yes 42f007083e671014

root@pc1:/home/hamiltonp/Desktop# touch ./1/2/file
touch: cannot touch './1/2/file': Permission denied

/\ It's unlocked now with 0.2.0, but I just can't write anything inside the encrypted dir, neither on command line nor file manager (even after changing the permissions to a normal user account).

[josephlr]

@HamiltonP My guess would be this is caused by how the kernel keyring is being managed. Can you run the following commands as root and as the user account:

keyctl show
keyctl show @u
fscrypt status /home/hamiltonp/Desktop/1/2 --verbose

This requires the keyutils package to be installed.

I'm going to do some more investigation into how you might be hitting this issue.

[josephlr]

I have figured out the problem. Some background can be found in #34. Because of systemd/keyring nonsense, we have to store all keys in the user's user keyring. This normally works fairly well as many sessions generally share the user keyring. However, this becomes a problem when a user switches between the root account and their own unprivileged account (i.e. they are a sudoer). There are two cases to consider here:

1. root cannot access keys provisioned by other users - Solved here by linking the user keyring into the root user keyring

2. other users cannot access keys provisioned by root - This is harder to fix, and it is what you are running into. It is also complicated by the fact that a session as root, started with sudo, may still be using the users session keyring. And because users do not automatically possess their user keyring (unlike their thread, process, and session keyrings), you can end up with the situation where root does not possess it's own user keyring.

Fixing 2 will be hard. The approach I may use is just to make sure fscrypt unlock and fscrypt encrypt are not run by root unless the user really knows what they are doing. Another approach would be to have a global keyring containing the necessary keys, but that will not work because of a security issue in the keyrings API we are having trouble getting patched (see discussion here and here).

@josephlr

root@pc1:/home/hamiltonp/Desktop# keyctl show
Session Keyring
873158299 --alswrv 1000 1000 keyring: _ses
648192401 ---lswrv 1000 65534 _ keyring: _uid.1000

root@pc1:/home/hamiltonp/Desktop# keyctl show @U
Keyring
994967886 --alswrv 0 65534 keyring: _uid.0
648192401 ---lswrv 1000 65534 _ keyring: _uid.1000
280061314 --alsw-v 0 0 _ logon: ext4:db44b9b1e846dd20
root@pc1:/home/hamiltonp/Desktop# fscrypt status /^C
root@pc1:/home/hamiltonp/Desktop# ls -l
total 260
-rw-r--r-- 1 root root 33554431 Aug 24 23:28 ext4
drwxr-xr-x 5 root root 4096 Aug 24 23:26 tmp

root@pc1:/home/hamiltonp/Desktop# fscrypt status /home/hamiltonp/Desktop/mountpoint/blah
"/home/hamiltonp/Desktop/mountpoint/blah" is encrypted with fscrypt.

Policy: db44b9b1e846dd20
Unlocked: Yes

Protected with 1 protector:
PROTECTOR LINKED DESCRIPTION
9533319c87938573 No custom protector "1"

root cannot access keys provisioned by other users - Solved here by linking the user keyring into the root user keyring

I've always thought that is intended security feature like some kind of MAC. Maybe it should be optional?

[josephlr]

@fancytenseletters, that's what I though initially, but it turns out root can access the keyrings of other users in a convoluted manner (either though /proc/keys or by just dropping privileges). However, the other users' keys will not automatically be visible to root in the context of filesystem encryption.

So the link keeps the security situation the same while improving usability.

[josephlr]

@HamiltonP This should be fixed with #52. fscrypt unlock blah/dir/ should no longer work as root, instead prompting you to specify a user with --user=USERNAME. Then, running fscrypt unlock blah/dir/ --user=hamiltonp as root should properly provision the keys.