aboutsummaryrefslogtreecommitdiff
path: root/metadata
AgeCommit message (Collapse)Author
2021-01-25Avoid using the word "whitelist"Eric Biggers
2020-05-09metadata: improve errorsEric Biggers
ErrBadOwners: Rename to ErrDirectoryNotOwned for clarity, move it from cmd/fscrypt/ to metadata/ where it better belongs, and improve the message. ErrEncrypted: Rename to ErrAlreadyEncrypted for clarity, and include the path. ErrNotEncrypted: Include the path. ErrBadEncryptionOptions: Include the path and bad options. ErrEncryptionNotSupported: ErrEncryptionNotEnabled: Don't wrap with "get encryption policy %s", in preparation for wrapping these with filesystem-level context instead. Also avoid mixing together the error handling for the "get policy" and "set policy" ioctls. Make it very clear how we're handling the errors from each ioctl.
2020-03-23Simplify choosing the key description prefixEric Biggers
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.
2020-01-05Metadata support for v2 encryption policiesEric Biggers
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.
2020-01-05keyring: support filesystem keyring with v1 encryption policiesEric Biggers
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.
2019-11-27Use latest fscrypt declarations from sys/unixEric Biggers
Use the new name for fscrypt constants and structures which have been given a new name. Also use the named constant for the DIRECT_KEY fscrypt policy flag. No change in behavior. This is just preparing for future work.
2019-01-14Add support for the Adiantum encryption modeEric Biggers
Add Adiantum support to the fscrypt userspace tool. Supported in the kernel since v5.0-rc1, Adiantum is a length-preserving encryption mode based primarily on XChaCha12. It is fast even on CPUs without AES instructions. Unlike XTS it is also a wide-block encryption mode. Adiantum is supported for both contents and filenames encryption. For Adiantum encryption policies, also make the fscrypt tool provide the new DIRECT_KEY flag, which further improves performance by requesting that all files be encrypted directly with the policy key. This takes advantage of Adiantum's support for long tweaks. See the kernel commit "fscrypt: add Adiantum support" (https://git.kernel.org/torvalds/c/8094c3ceb21ad938) for more details.
2018-08-30Go 1.11 gofmt updataeJoe Richey joerichey@google.com
2018-08-30Use proto.Equal instead of reflect.DeepEqualsJoe Richey joerichey@google.com
2018-08-30Update Protoc Compiler to 3.6.1Joe Richey joerichey@google.com
2018-02-12metadata: regenerate .pb.goJoseph Richey
2018-02-11vet: eliminate unnecessary shadowingJoseph Richey
Running "go vet -shadow ./..." finds all places where a variable might be incorrectly or unnecessarily shadowed. This fixes some of them.
2017-09-29metadata: Add new encryption modesJoseph Richey
2017-07-18metadata: Remove "go generate" and regenerateJoe Richey joerichey@google.com
2017-07-18tests: Unit tests and Integration tests workJoe Richey joerichey@google.com
Now the testing functions will skip the integration tests if a testing filesystem is not specified.
2017-07-18Travis.yml and Makefile now run integration tests.Joe Richey joerichey@google.com
2017-06-28Finalize import paths and documentationv0.1.00.1.0Joe Richey joerichey@google.com
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
2017-06-28Change error handling to new packageJoe Richey joerichey@google.com
This commit changes the error handing for the crypto, filesystem, metadata, pam, and util packages to use the error handling library github.com/pkg/errors. This means elimination of the FSError type, an increased use of wrapping errors (as opposed to logging), switching on the Cause() of an error (as opposed to its value), and improving our integration tests involving TEST_FILESYSTEM_ROOT. This commit also fixes a few bugs with the keyring code to ensure that our {Find|Remove|Insert}PolicyKey functions are always operating on the same keyring. The check for filesystem support has been moved from the filesystem package to the metadata package. Finally, the API for the filesystem package has been slightly modified: * filesystem.AllFilesystems() now returns all the filesystems in sorted order * certain path methods are now public O_SYNC is also removed for writing the metadata. We don't get that much from syncing the metadata, as the actual file data could also be corrupted by and IO error. The sync operation is also occasionally very slow (~3 seconds) and can be unfriendly to battery life. Change-Id: I392c2655141714b16dfdbc84ac09780072be2cf0
2017-06-15metadata: change encryption mode namesJoe Richey joerichey@google.com
As new encryption modes are being added to the kernel that use 128 bit keys (see https://patchwork.kernel.org/patch/9741913), we will need the encryption modes to be more descriptive. This change breaks backwards compatibility for the protobuf, but that's fine because we have not released yet. Change-Id: Ifb58d3d5a42db491f1e5393c12f3d260d9a091de
2017-05-31metadata: reorganize and add consistency checksJoe Richey joerichey@google.com
This commit adds in IsValid() checks for the metadata structures that let us enforce stronger invariants than those imposed by the protobuf package. The main uses of this will be to check that metadata is valid before writing it to the filesystem, and to check that the filesystem contains valid metadata before returning it to the user. These functions also will log the exact reason if the validity checks fail. To have these checks in the metadata package, all of the various constants have been moved to a single metadata/constants.go file. The uses of these constants were changed accordingly. Finally, this commit standardizes our use of errors so that they always begin with an appropriate prefix. Change-Id: I99008e2ee803ebe5f6236eb8d83fc83efcd22718
2017-05-02crypto: insert key into keyring from goJoe Richey
This commit adds in the ability to insert Keys into the kernel keyring from go code. This is done via a patched version of x/sys/unix. We also expose the specific requirements for keys that will be placed in the keyring, namely PolicyKeyLen. The legacy services are also exposed. Change-Id: I177928c9aa676cae13b749042b9a3996e7490f68
2017-05-02metadata: get and set policies from goJoe Richey
This commit adds in the ability to get and set policy data from go using the GetPolicy and SetPolicy functions. This is done via a patch of the x/sys/unix package that exposes the filesystem encryption structures. Note that not all the fields of the PolicyData protocol buffer are needed to get and set policies. The wrapped_policy_keys are not used and will be written and read by other components of fscrypt. To run the policy tests, the environment variable BASE_TEST_DIR must be set to a directory for testing on a filesystem that supports encryption. Change-Id: I13b1d983356845f3ffc1945cedf53234218f32e5
2017-05-02metadata: introduce protobuf structuresJoe Richey
This commit adds in the metadata package. The primary purpose of this package is to provide the on-disk metadata structures in the form of protocol buffers. This includes: - Policy metadata structure - Protector metadata structure - Config file structure - All necessary sub-structures (wrapped keys, parameters, etc) This commit also adds in an example usage of the Config structure, which represents the structure of the global config file. All the package does at this point is convert between the Config structure and a JSON representation. Here we introduce govendor, which is described more in the README. This means we will have all of our Go dependencies in the vendor subdirectory. This means we will have no Go source dependencies, only dependencies on the build tools (Go and govendor). The README describes this in detail. Note that we commit the generated files. see: https://blog.golang.org/generate Change-Id: Iaacd46666b5d3e4e865a0f4045dd63ed7e3d6f96