From: Yu Watanabe Date: Sat, 25 Jul 2026 10:36:35 +0000 (+0900) Subject: homed/fscrypt: default new homes to v2 policies (#18280) (#42397) X-Git-Url: http://git.ipfire.org/gitweb/?a=commitdiff_plain;h=d20313d0865a30cb1f57e03392d38fbfcaaf8cce;p=thirdparty%2Fsystemd.git homed/fscrypt: default new homes to v2 policies (#18280) (#42397) ## Summary Closes #18280. `systemd-homed` currently writes fscrypt v1 policies, which bind the master key to the calling process's keyring. This means files in a homed-managed directory aren't readable when accessed through a container bind mount, a different mount namespace, or by any process other than the one that first unlocked the home. Reading the file from a context that has the key first warms the page cache, but the underlying problem remains. v2 policies (Linux 5.4+) route the master key through the filesystem keyring, via `FS_IOC_ADD_ENCRYPTION_KEY` / `FS_IOC_REMOVE_ENCRYPTION_KEY`, so the key is visible to every process accessing the filesystem. This PR switches `systemd-homed` to v2 by default and keeps existing v1 homes working. ## Changes **`shared/crypto-util`**: Add `kdf_hkdf_derive` (HKDF, RFC 5869) wrapper around OpenSSL's `EVP_KDF` "HKDF", alongside the existing SSKDF/KBKDF helpers. **`homed/fscrypt`**: - Read the existing policy via `FS_IOC_GET_ENCRYPTION_POLICY_EX`, falling back to the legacy ioctl on pre-5.4 kernels. - `HomeSetup` now carries a full `struct fscrypt_key_specifier` instead of a bare 8-byte descriptor. Slot decryption derives either the v1 descriptor (double SHA-512) or the v2 identifier (HKDF-SHA512 with the kernel's info string) from the unwrapped volume key and compares against the policy. - Install the master key the right way per version: `add_key("logon", ...)` to thread+user keyrings for v1, `FS_IOC_ADD_ENCRYPTION_KEY` for v2. - `home_flush_keyring_fscrypt` opens the image directory, reads the policy version, and either calls `FS_IOC_REMOVE_ENCRYPTION_KEY` (v2) or walks the user keyring (v1). - New homes default to v2; fall back to v1 only when the kernel rejects v2. The on-disk slot xattr format is unchanged - the volume key is the same, only how it binds to the directory changes. There is no v1 -> v2 migration; existing v1 homes continue to unlock, rekey, and deactivate as before. --- d20313d0865a30cb1f57e03392d38fbfcaaf8cce