| Age | Commit message (Collapse) | Author |
|---|
|
Now that it's been requested by users, bring back the "unlock_only"
option, which was originally proposed as part of
https://github.com/google/fscrypt/pull/281 but was dropped in the final
version of that pull request.
Resolves https://github.com/google/fscrypt/issues/357
|
|
Support for AES_256_HCTR2 filenames encryption was added in kernel
version 6.0. The kernel doesn't yet support AES_256_HCTR2 for contents
encryption.
|
|
|
|
Bump up the required Go version to 1.16 so that we can assume that Go
modules are enabled by default. Go 1.16 is the latest end-of-life
release, so this makes it so that we support the latest end-of-life
release (1.16), the current maintainance release (1.17), the current
release (1.18), and future releases. This the same approach we took
when we last bumped up the required Go version.
Also update the ci.yml file to test with these versions.
|
|
Currently, fscrypt policies and protectors are world readable, as they
are created with mode 0644. While this can be nice for use cases where
users share these files, those use cases seem to be quite rare, and it's
not a great default security-wise since it exposes password hashes to
all users. While fscrypt uses a very strong password hash algorithm, it
would still be best to follow the lead of /etc/shadow and keep this
information non-world-readable.
Therefore, start creating these files with mode 0600.
Of course, if users do actually want to share these files, they have the
option of simply chmod'ing them to a less restrictive mode. An option
could also be added to make fscrypt use the old mode 0644; however, the
need for that is currently unclear.
|
|
The metadata validation checks introduced by the previous commits are
good, but to reduce the attack surface it would be much better to avoid
reading and parsing files owned by other users in the first place.
There are some possible use cases for users sharing fscrypt metadata
files, but I think that for the vast majority of users it is unneeded
and just opens up attack surface. Thus, make fscrypt (and pam_fscrypt)
not process policies or protectors owned by other users by default.
Specifically,
* If fscrypt or pam_fscrypt is running as a non-root user, only
policies and protectors owned by the user or by root can be used.
* If fscrypt is running as root, any policy or protector can be used.
(This is to match user expectations -- starting a sudo session
should gain rights, not remove rights.)
* If pam_fscrypt is running as root, only policies and protectors
owned by root can be used. Note that this only applies when the
root user themselves has an fscrypt login protector, which is rare.
Add an option 'allow_cross_user_metadata' to /etc/fscrypt.conf which
allows restoring the old behavior for anyone who really needs it.
|
|
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.
|
|
|
|
Fixes https://github.com/google/fscrypt/issues/318
|
|
"Linux filesystem encryption" sounds too vague. Write "Linux native
filesystem encryption" instead.
|
|
Update https://github.com/google/fscrypt/issues/321
Update https://github.com/google/fscrypt/issues/324
|
|
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
|
|
Resolves https://github.com/google/fscrypt/issues/305
|
|
Update https://github.com/google/fscrypt/issues/115
|
|
|
|
Capitalize the first word only, and don't use periods.
|
|
Resolves https://github.com/google/fscrypt/issues/51
Resolves https://github.com/google/fscrypt/issues/115
|
|
A lot of people are already using fscrypt, so in practice we haven't
been breaking backwards compatibility and aren't going to. Just remove
the scary-sounding "Note about stability".
|
|
These would still be nice to add. However, the mention of them in the
README is misleading because people reading it might come away with the
impression that there is currently no way to back up fscrypt metadata or
to recover directories -- which isn't true. (The fscrypt metadata is
just a directory which can be backed up like any other directory. And
'fscrypt encrypt' already offers to generate a recovery passphrase when
the directory and protector are on different filesystems.)
Just remove this note; it doesn't really add any value.
|
|
Update https://github.com/google/fscrypt/issues/305
|
|
Clarify some of the troubleshooting documentation.
|
|
Inspired by https://reddit.com/r/linuxquestions/comments/n75dv4
|
|
Fixes https://github.com/google/fscrypt/issues/194
Update https://github.com/google/fscrypt/issues/100
|
|
Rename the troubleshooting section "Can't log in with ssh even when
user's encrypted home directory is unlocked" to the more general "Some
processes can't access unlocked encrypted files", and rewrite it to
provide clearer directions for how to fix the problem by upgrading
encrypted directories to policy version 2.
Also add a related section "Users can access other users' unlocked
encrypted files" which covers the reverse "issue", i.e. people expecting
some processes to *not* be able to access unlocked encrypted files.
Fixes https://github.com/google/fscrypt/issues/248
|
|
Update https://github.com/google/fscrypt/issues/273
|
|
This is currently broken, and we don't really use the findings.
Signed-off-by: Joe Richey <joerichey@google.com>
|
|
Make some more corrections:
- pam-config-framework isn't actually Ubuntu-specific but actually
applies to Debian and any Debian derivative.
- The pam-config-framework file is indeed installed by `make install`,
just not into the correct location.
- On Debian (and Debian derivatives), the PAM configuration isn't
actually part of the 'fscrypt' package but rather 'libpam-fscrypt'.
- Clarify where to add the pam_fscrypt.so session hook.
|
|
There are several mentions of pam_fscrypt handling unlocking
directories. Make sure to mention locking alongside this.
|
|
All pam_fscrypt configuration guides that I'm aware of say to use the
"lock_policies" option for the pam_fscrypt.so session hook. The
Debian/Ubuntu pam-config-framework config file has it too.
Make locking the default behavior, since this is what everyone wants.
Existing configuration files that contain the "lock_policies" option
will continue to work, but that option won't do anything anymore.
(We could add an option "unlock_only" to restore the old default
behavior, but it's not clear that it would be useful. So for
simplicity, leave it out for now.)
|
|
Configuring whether pam_fscrypt drops caches or not isn't really
something the user should have to do, and it's also irrelevant for v2
encryption policies (the default on newer systems). It's better to have
pam_fscrypt automatically decide whether it needs to drop caches or not.
Do this by making pam_fscrypt check whether any encryption policy keys
are being removed from a user keyring (rather than from a filesystem
keyring). If so, it drops caches; otherwise it doesn't. This
supersedes the "drop_caches" option, which won't do anything anymore.
|
|
|
|
Workflow names are case-sensitive
Signed-off-by: Joe Richey <joerichey@google.com>
|
|
travis-ci.org is being shut down, so switch to GitHub Actions.
It should be mostly equivalent, but I did drop functionality in a couple
cases:
- Publishing release binaries. I don't think providing Linux binaries
is useful, since people build their own anyway. So I left this out.
- Build and testing on ppc64le. GitHub Actions only natively supports
x86. I tried uraimo/run-on-arch-action, which uses Docker and QEMU
user-mode emulation, but the fscrypt tests can't be run because
QEMU user-mode emulation doesn't support all the needed system calls.
|
|
|
|
Ubuntu's PAM configuration framework only recognizes files in /usr, not
/usr/local. So for installs from source, unfortunately we have to
recommend installing to /usr, despite this not being conventional.
Resolves https://github.com/google/fscrypt/issues/240
|
|
Explicitly mention that "fscrypt" here means the userspace tool, not the
kernel part. Also write `fscrypt` in code font to emphasize this.
|
|
|
|
Update https://github.com/google/fscrypt/issues/220
|
|
Update https://github.com/google/fscrypt/issues/220
|
|
- Mention that a v5.4+ kernel is recommended.
- Mention that policy_version defaults to 1 when unset.
- Emphasize that v2 policies are the recommended solution to the key
visibility problems, and add some more information.
|
|
Since on new kernels v1 encryption policies are deprecated in favor of
v2, update the examples to show v2. This mostly just consists of
updating the output, as the commands are essentially the same with one
notable difference in 'fscrypt lock'.
|
|
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.
|
|
|
|
When 'fscrypt setup' sees that /etc/fscrypt.conf doesn't exist, don't
ask for confirmation before creating it. Just do it. This is the
normal use, and there's not a good reason to ask the user to confirm it.
|
|
Resolves https://github.com/google/fscrypt/issues/181
|
|
Document the new /etc/fscrypt.conf settings for the filesystem keyring
and v2 encryption policies, and add a new subsection for troubleshooting
key access problems.
|
|
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.
|
|
Linux v5.4 and later supports v2 encryption policies. These have
several advantages over v1 encryption policies:
- Their encryption keys can be added/removed to/from the filesystem by
non-root users, thus gaining the benefits of the filesystem keyring
while also retaining support for non-root use.
- They use a more standard, secure, and flexible key derivation
function. Because of this, some future kernel-level fscrypt features
will be implemented for v2 policies only.
- They prevent a denial-of-service attack where a user could associate
the wrong key with another user's encrypted files.
Prepare the fscrypt tool to support v2 encryption policies by:
- Adding a policy_version field to the EncryptionOptions, i.e. to the
config file and to the policy metadata files.
- Using the kernel-specified algorithm to compute the key descriptor for
v2 policies.
- Handling setting and getting v2 policies.
Actually adding/removing the keys for v2 policies to/from the kernel is
left for the next patch.
|
|
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.
|
|
|
