| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
Make remove-protector-from-policy work even if the protector cannot be
loaded (for example, due to having been deleted already).
Fixes https://github.com/google/fscrypt/issues/258
Fixes https://github.com/google/fscrypt/issues/272
|
|
Introduce filesystem.ErrEncryptionNotEnabled and
filesystem.ErrEncryptionNotSupported which include the Mount as context,
and translate the corresponding metadata/ errors into them. Then make
these errors show much better suggestions.
Also replace lots of other filesystem/ errors with either custom types
or with unnamed one-off errors that include more context. Fix backwards
wrapping in lots of cases.
Finally, don't include the mountpoint in places where it's not useful,
like OS-level errors that already include the path.
|
|
ErrMissingPolicyMetadata:
Include the mount, directory path, and metadata path. Also move
the explanation into actions/ since it doesn't refer to any CLI
command.
ErrPolicyMetadataMismatch:
Include a lot more information. Also start checking for
consistency of the policy key descriptors, not just the
encryption options. Add a test for this.
ErrDifferentFilesystem:
Include the mountpoints.
ErrOnlyProtector:
Clarify the message and include the protector descriptor.
ErrAlreadyProtected:
ErrNotProtected:
Include the policy and protector descriptors.
ErrAccessDeniedPossiblyV2:
Make it slightly clearer what failed. Also move the explanation
into actions/ since it doesn't refer to any CLI command.
|
|
'fscrypt lock' on a v1-encrypted directory doesn't warn about in-use
files, as the kernel doesn't provide a way to easily detect it.
Instead, implement a heuristic where we check whether a subdirectory can
be created. If yes, then the directory must not be fully locked.
Make both 'fscrypt lock' and 'fscrypt status' use this heuristic.
Resolves https://github.com/google/fscrypt/issues/215
|
|
If trying to unlock a v2-encrypted directory fails because the kernel
lacks support for v2 policies, show a better error message. This can
happen if someone downgrades their kernel or tries to access encrypted
directories on removable storage from a computer with an older kernel.
Detecting this case is difficult since all we have to go with is EACCES
when opening the directory. Implement a heuristic where if get EACCES,
we actually have read access to the directory, and the kernel doesn't
support v2 policies, we show the improved error message.
Before:
# fscrypt unlock dir
[ERROR] fscrypt unlock: open dir: permission denied
After:
# fscrypt unlock dir
[ERROR] fscrypt unlock: open dir: permission denied
This may be caused by the directory using a v2 encryption policy and
the current kernel not supporting it. If indeed the case, then this
directory can only be used on kernel v5.4 and later. You can create
directories accessible on older kernels by changing policy_version to
1 in /etc/fscrypt.conf.
|
|
Ensure that when an encryption policy is reverted (e.g. due to
encryptPath() failing after the policy was created), we also delete any
new protector links that were created for the policy, as this is not
handled by the logic that reverts new protectors.
|
|
When adding a protector to a policy, don't unconditionally overwrite the
protector link, because it may already exist. Instead, if it already
exists and points to the mount, just use it. If it already exists and
points to the wrong place, return an error.
Also add a bool to the return value of AddLinkedProtector() so that
callers can check whether the link was newly created or not.
|
|
Allow root to provide the --all-users option to 'fscrypt lock' to force
an encryption key to be removed from the filesystem (i.e., force an
encrypted directory to be locked), even if other users have added it.
To implement this option, we just need to use the
FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS ioctl rather than
FS_IOC_REMOVE_ENCRYPTION_KEY.
In theory this option could be implemented for the user keyrings case
too, but it would be difficult and the user keyrings are being
deprecated for fscrypt, so don't bother.
|
|
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.
|
|
FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY require root
for v1 policy keys, so update the PAM module to re-acquire root
privileges while provisioning/deprovisioning policies that need this.
Also, only set up the user keyring if it will actually be used.
|
|
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.
|
|
Linux v5.4 and later allows fscrypt keys to be added/removed directly
to/from the filesystem via the new ioctls FS_IOC_ADD_ENCRYPTION_KEY and
FS_IOC_REMOVE_ENCRYPTION_KEY. Among other benefits, these fix the key
visibility problems that many users have been running into, where system
services and containers can't access encrypted files.
Allow the user to opt-in to using these new ioctls for their existing
encrypted directories by setting in their /etc/fscrypt.conf:
"use_fs_keyring_for_v1_policies": true
Note that it can't really be on by default, since for v1 policies the
ioctls require root, whereas user keyrings don't. I.e., setting this to
true means that users will need to use 'sudo fscrypt unlock', not
'fscrypt unlock'. v2 policies won't have this restriction.
|
|
In preparation for introducing support for the new filesystem-level
keyrings, move the existing user keyring management code from
security/keyring.go and crypto/crypto.go into a new package, 'keyring'.
This package provides functions AddEncryptionKey, RemoveEncryptionKey,
and GetEncryptionKeyStatus which delegate to either the filesystem
keyring (added by a later patch) or to the user keyring. This provides
a common interface to both types of keyrings, to the extent possible.
|
|
Show the encryption options when running 'fscrypt status' on a
directory. E.g.:
Policy: 490515286453d3f7
Options: padding:32 contents:Adiantum filenames:Adiantum
Unlocked: Yes
|
|
These were found by a combination of manual review and a custom script
that checks for common errors.
Also removed an outdated sentence from the comment for setupBefore().
|
|
|
|
Now instead of spawning a seperate thread we alternate between changing
the euid and ruid to both find the keyring and link it to the process
keyring. Note that we also ensure that the user keyring is linked into
the root keyring whenever possible.
|
|
This user is used with policies to interface with the keryings and with
protectors to indicate which user's login passphrase should be used to
protectors of type pam_passphrase.
|
|
|
|
|
|
|
|
|
|
In addition to using callbacks, unlocked Protectors can now directly
unlock a policy. The error codes are updated to make more sense.
|
|
|
|
This commit changes all the internal import paths from `fscrypt/foo` to
`github.com/google/fscrypt/foo` so that it can be built once we release
externaly. The documentation in README.md is updated accordingly.
Also, the README has a note noting that we do not make any guarantees
about project stability before 1.0 (when it ships with Ubuntu).
Change-Id: I6ba86e442c74057c8a06ba32a42e17f94833e280
|
|
This commit changes the error handling for the actions package to use
the error handling library github.com/pkg/errors. This means replacing
"errors" with "github.com/pkg/errors", reworking some of the error
values, and wrapping some errors with additional context.
This commit also changes the Protector/Policy API, moving most of the
package functionality into Protector or Policy methods. These types are
now "locked" when they are queried from the filesystem, and Unlock()
must be used to get their corresponding keys. Note that only certain
operations will require unlocking the keys. Certain unnecessary
functions and methods are also removed.
This CL also fixes two bugs reported by Tyler Hicks in CreateConfigFile.
CPU time is used instead of wall time, and kiB is used instead of kB.
Change-Id: I88f45659e9fe4938d148843e3289e7b6d5b698d8
|
|
This commit makes the callbacks for getting keys easier to understand.
Functions which need keys now take a KeyFunc callback. This callback
contains a ProtectorInfo parameter (basically a read-only version of
metadata.ProtectorData) and a boolean which indicates if the call is
being retried. The documentation is also updated to say which functions
will retry the KeyFunc.
For selecting a protector, there is now an OptionFunc callback which
takes a slice of ProtectorOptions. A ProtectorOption is a ProtectorInfo
along with additional information about a linked filesystem (if
applicable).
This commit also adds in methods for getting the protector options for a
specific filesystem or policy. It also adds a function for getting the
policy descriptor for a specific path.
Change-Id: I41e0d94ffd44e7166b0c5cf1b5d18437960bdf90
|
|
This commit adds in the Policy structure. This structure represents an
unlocked policy key and its associated data. Policies can add or remove
Protectors, apply encryption policies to filesystem directories, and
provision a key into the kernel keyring.
Change-Id: I089710223221e0ea60188d523703469e5d67ad0e
|
