fscrypt.git/cli-tests/t_encrypt_login.sh, branch v0.3.5 Go tool for managing Linux filesystem encryption Make all new metadata files owned by user when needed 2022-02-23T20:35:04+00:00 Eric Biggers ebiggers@google.com 2022-02-23T20:35:04+00:00 d4ce0b892cbe68db9f90f4015342e6a9069b079c Since commit 4c7c6631cc5a ("Set owner of login protectors to correct user"), login protectors are made owned by the user when root creates one on a user's behalf. That's good, but the same isn't true of other files that get created at the same time: - The policy protecting the directory - The protector link file, if the policy is on a different filesystem - The recovery protector, if the policy is on a different filesystem - The recovery instructions file In preparation for setting all metadata files to mode 0600, start making all these files owned by the user in this scenario as well. 
Since commit 4c7c6631cc5a ("Set owner of login protectors to correct
user"), login protectors are made owned by the user when root creates
one on a user's behalf.  That's good, but the same isn't true of other
files that get created at the same time:

- The policy protecting the directory
- The protector link file, if the policy is on a different filesystem
- The recovery protector, if the policy is on a different filesystem
- The recovery instructions file

In preparation for setting all metadata files to mode 0600, start making
all these files owned by the user in this scenario as well.
cli-tests: fix broken test 2022-01-19T19:07:03+00:00 Eric Biggers ebiggers@google.com 2022-01-19T19:07:00+00:00 6eb31650b4dc42cd0a40a962a0d513eeb827d9f5 I'm not sure how this passed the GitHub checks. 
I'm not sure how this passed the GitHub checks.
Merge pull request #337 from google/broken-links 2022-01-19T05:11:01+00:00 Eric Biggers ebiggers@google.com 2022-01-19T05:11:01+00:00 fac30865c04de8f4698776e94dd86c7a88fd5da2 filesystem: store mountpoint in link files as a fallback 
filesystem: store mountpoint in link files as a fallback
 cli-tests: add helper functions to get protector descriptors 2021-12-23T17:39:08+00:00 Eric Biggers ebiggers@google.com 2021-12-23T17:39:08+00:00 57be034ce4700fb07c10b771628c1c63d8483d09 






filesystem: store mountpoint in link files as a fallback
2021-12-23T04:46:16+00:00

Eric Biggers
ebiggers@google.com

2021-12-23T04:46:16+00:00

5ae7da4ee6582099de5d1b14733f8d58f4dc2816

Currently, linked protectors use filesystem link files of the form
"UUID=<uuid>".  These links get broken if the filesystem's UUID changes,
e.g. due to the filesystem being re-created even if the ".fscrypt"
directory is backed up and restored.

To prevent links from being broken (in most cases), start storing the
mountpoint path in the link files too, in the form
"UUID=<uuid>\nPATH=<path>\n".  When following a link, try the UUID
first, and if it doesn't work try the PATH.  While it's possible that
the path changed too, for login protectors (the usual use case of linked
protectors) this won't be an issue as the path will always be "/".

An alternative solution would be to fall back to scanning all
filesystems for the needed protector descriptor.  I decided not to do
that, since relying on a global scan doesn't seem to be a good design.
It wouldn't scale to large numbers of filesystems, it could cross
security boundaries, and it would make it possible for adding a new
filesystem to break fscrypt on existing filesystems.  And if a global
scan was an acceptable way to find protectors during normal use, then
there would be no need for link files in the first place.

Note: this change is backwards compatible (i.e., fscrypt will continue
to recognize old link files) but not forwards-compatible (i.e., previous
versions of fscrypt won't recognize new link files).

Fixes https://github.com/google/fscrypt/issues/311





Currently, linked protectors use filesystem link files of the form
"UUID=<uuid>".  These links get broken if the filesystem's UUID changes,
e.g. due to the filesystem being re-created even if the ".fscrypt"
directory is backed up and restored.

To prevent links from being broken (in most cases), start storing the
mountpoint path in the link files too, in the form
"UUID=<uuid>\nPATH=<path>\n".  When following a link, try the UUID
first, and if it doesn't work try the PATH.  While it's possible that
the path changed too, for login protectors (the usual use case of linked
protectors) this won't be an issue as the path will always be "/".

An alternative solution would be to fall back to scanning all
filesystems for the needed protector descriptor.  I decided not to do
that, since relying on a global scan doesn't seem to be a good design.
It wouldn't scale to large numbers of filesystems, it could cross
security boundaries, and it would make it possible for adding a new
filesystem to break fscrypt on existing filesystems.  And if a global
scan was an acceptable way to find protectors during normal use, then
there would be no need for link files in the first place.

Note: this change is backwards compatible (i.e., fscrypt will continue
to recognize old link files) but not forwards-compatible (i.e., previous
versions of fscrypt won't recognize new link files).

Fixes https://github.com/google/fscrypt/issues/311







Set owner of login protectors to correct user
2021-12-20T03:44:59+00:00

Eric Biggers
ebiggers@google.com

2021-12-20T03:19:25+00:00

4c7c6631cc5a27cc6b4431f5ad3805a2d624c5f5

When the root user creates a login protector for a non-root user, make
sure to chown() the protector file to make it owned by the user.
Without this, the protector cannot be updated by the user, which causes
it to get out of sync if the user changes their login passphrase.

Fixes https://github.com/google/fscrypt/issues/319





When the root user creates a login protector for a non-root user, make
sure to chown() the protector file to make it owned by the user.
Without this, the protector cannot be updated by the user, which causes
it to get out of sync if the user changes their login passphrase.

Fixes https://github.com/google/fscrypt/issues/319







Adjust recovery passphrase generation
2021-10-05T22:30:30+00:00

Eric Biggers
ebiggers@google.com

2021-09-14T21:12:39+00:00

7fed63a84963cbd790e86a0e59ff14724bcf33c4

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





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







cli-tests: add t_encrypt_login
2020-05-09T21:04:47+00:00

Eric Biggers
ebiggers@google.com

2020-05-09T21:04:47+00:00

280c466cff982ff536016cc35cc135dd439782a4

Test encrypting a directory using a login (pam_passphrase) protector.





Test encrypting a directory using a login (pam_passphrase) protector.