Signed-off-by: Joe Richey <joerichey@google.com>
[ebiggers: moved the new checks from PassphraseHash to CheckValidity]
Signed-off-by: Eric Biggers <ebiggers@google.com>

This allows us to fix the bug where Parallelism is inadvertantly
truncated to 8 bits in a backwards compatible way.

Signed-off-by: Joe Richey <joerichey@google.com>

We now create the `*pb.go` files via the makefile instead of though
`go generate`.

Signed-off-by: Joe Richey <joerichey@google.com>

Since Go 1.16 (which recently became the minimum supported Go version
for this project), the package io/ioutil is deprecated in favor of
equivalent functionality in the io and os packages.  staticcheck warns
about this.  Address all the warnings by switching to the non-deprecated
replacement functions.

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.

Follow up to #362

Protojson randomly inserts whitespace to indicate that the output is
unstable, breaking out tests. To fix this, compact the output before
comparison.

Signed-off-by: Joe Richey <joerichey@google.com>

Signed-off-by: Joe Richey <joerichey@google.com>

Split policyIoctl into setPolicyIoctl and getPolicyIoctl. Add a
os.Sync() call to setPolicyIoctl.

Policy ioctls are not necessary durable on return. For example, on
ext4 (ref: fs/ext4/crypto.c: ext4_set_context) they are not. This may
lead to a filesystem containing fscrypt metadata (in .fscrypt), but
without the policy applied on an encrypted directory.

Example:
Snapshotting a mounted ext4 filesystem on Ceph RBD right after
setting the policy. While subject to timing, with high probability the
snapshot will not have the policy set. Calling fsync fixes this.

Signed-off-by: Marcel Lauhoff <marcel.lauhoff@suse.com>

github.com/golang/protobuf/proto has been deprecated in favor of
google.golang.org/protobuf/proto, so migrate to the non-deprecated one.

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.