| Age | Commit message (Collapse) | Author |
|---|
|
ErrKeyLock:
Rename to ErrMlockUlimit for clarity.
ErrGetrandomFail:
ErrKeyAlloc:
ErrKeyFree:
ErrNegativeLength:
Replace these with one-off unnamed errors because these were all
returned in only one place and were never checked for. Also
these were all either wrapped backwards or discarded an
underlying error, so fix that too.
|
|
If a user re-installs their system (or otherwise loses the /.fscrypt
directory on the root filesystem) they also lose access to any login
passphrase-protected directories on other filesystems, unless additional
protectors were manually added. This can be unexpected, as it may be
expected that the old login passphrase would still work.
We can't really fix this by storing a login protector on every
filesystem because:
- If a user were to have N login protectors, it would take them N times
longer to log in, as every login protector would need to be unlocked.
- If a user were to change their login passphrase while any external
volumes were unmounted, login protectors would get out of sync.
- It's preferable that an external volume isn't unlockable by itself
using only a login passphrase, as login passphrases are often weak.
Instead, generate a recovery passphrase when creating a login
passphrase-protected directory on a non-root filesystem.
The recovery passphrase is added as a custom_passphrase protector, thus
giving the policy two protectors: one pam_passphrase and one
custom_passphrase. Then this passphrase is written to a file in the new
encrypted directory. Writing the passphrase to a file here is okay
since it's encrypted, but it's obviously useless by itself; it's up to
the user to store this passphrase somewhere else if they need it.
Use a recovery passphrase instead of a "recovery code" that encodes the
policy key directly because a passphrase is more user-friendly: it can
safely be made much shorter than a key, and it works just like any other
fscrypt protector. Also, it's not as critical to allow recovery when
the .fscrypt directory on the *same* filesystem is deleted.
Resolves https://github.com/google/fscrypt/issues/164
|
|
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.
|
|
Refer to the target User as 'targetUser' rather than simply 'target'.
This will help avoid confusion when we add support for the filesystem
keyring, since then the Mount will also be a "target".
|
|
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().
|
|
Running "go vet -shadow ./..." finds all places where a variable might
be incorrectly or unnecessarily shadowed. This fixes some of them.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Instead of using the service+descriptor parameters (which are always
combined in the same way), use a single description parameter.
|
|
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 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
|
|
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 updates the vendored x/sys/unix to the current version. This
means that our vendored version of x/sys/unix no longer contains custom
patches. A few changes are needed in InsertPolicyKey() as the final API
differed slightly from our patches.
Change-Id: Ifff31c04e708f9dc4395ab5bfcc94e42fb46dea5
|
|
This commit adds in the FindPolicyKey and RemovePolicyKey functions to
complement the InsertPolicyKey function. The existing functions were
also refactored slightly.
Change-Id: Iabd275f2186a9e3023d5efd44c772966123e3657
|
|
This changes the crypto package so it now builds in light of the changes
to the util and metadata package. This commit also improves the error
handling, adds tests, and makes it so recovery keys now correspond to
Policy keys (as they are used to recover a directory in the absence of
any metadata).
The only feature addition here is the ability to compute descriptors.
For backwards compatibility, we keep the same descriptor algorithm used
before (double SHA512).
Change-Id: Ia2b53c6e85ce65c57595e6823d3c4c92219bc8dc
|
|
This commit adds in the concept of recovery codes: human-readable
strings that contain the necessary information to rederive a
cryptographic key. These keys look like:
73PZBXVP-DKJX7SKV-NNTFIC7A-QEGRPZUX-4K5ORRH2-MTKMKP3B-HFCA====
They are input or output directly to a io.Reader or io.Writer
respectively. This prevents the data from passing through unsecured
memory before it gets to its destination. Of course, if the provided
io.Reader or io.Writer is insecure, there is nothing we can do. In most
cases the provided io.Reader or io.Writer will be stdin or stdout. In
some rare cases you might want to pipe the output to another key.
This commit also adds tests and benchmarks for encoding/decoding
recovery codes. It also tests that encoding/decoding will fail in the
correct situations. A benchmark is also added to measure the effect of
locking the keys in memory.
Change-Id: Ifa0bc4c08582789785cf1cdd9a4acfe76c79534f
|
|
This commit adds in the ability to use the WrappedKeyData from the
metadata package to wrap and unwrap cryptographic keys of any length.
This makes use of several cryptographic primitives:
- Unsalted, SHA256-based HKDF for key stretching
- AES256 in CTR mode for encryption
- SHA256-based HMAC for authentication
Note that the key wrapping/unwrapping uses an "Encrypt then MAC" scheme
for doing authenticated unwrapping. This means we can detect if bogus
metadata has been given. This package also standardizes the length for
fscrypt's internal keys.
This CL is the first to add benchmarks, which can be run with:
go test -bench=. ./...
Change-Id: I2e5fc23a8a8cc36b17ccb3f26f03edcaccc517e1
|
|
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
|
|
This commit adds in the crypto package, which will hold all
of the security primitives for fscrypt. This first component deals with
securely handling keys in memory. To do this in a consistent way across
fscrypt, we introduce the Key struct.
Any sensitive memory (like keys, passwords, or recovery tokens) in
fscrypt will be held in a Key. No code outside of the crypto package
should access the Key's data directly. Convenience functions and methods
are provided to construct keys from io.Readers (either with fixed length
or with variable length) and to access information about the Keys.
The most important property of Keys is that the data is locked in memory
on construction, and the data is unlocked and wiped when Wipe is called.
This happens either by something like "defer key.Wipe()" or through the
finalizer.
Change-Id: Ice76335f3975efb439b3f1ab605ef34cb7fcb4d6
|
