From 462d166d5355d33a05271d24de4d52f30dd62f67 Mon Sep 17 00:00:00 2001 From: Eric Biggers Date: Sun, 15 Dec 2019 19:31:39 -0800 Subject: Add keyring package 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. --- actions/context.go | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'actions/context.go') diff --git a/actions/context.go b/actions/context.go index 5a56789..7703db5 100644 --- a/actions/context.go +++ b/actions/context.go @@ -37,6 +37,7 @@ import ( "github.com/pkg/errors" "github.com/google/fscrypt/filesystem" + "github.com/google/fscrypt/keyring" "github.com/google/fscrypt/metadata" "github.com/google/fscrypt/util" ) @@ -145,6 +146,13 @@ func (ctx *Context) getService() string { return unix.FSCRYPT_KEY_DESC_PREFIX } +func (ctx *Context) getKeyringOptions() *keyring.Options { + return &keyring.Options{ + User: ctx.TargetUser, + Service: ctx.getService(), + } +} + // getProtectorOption returns the ProtectorOption for the protector on the // context's mountpoint with the specified descriptor. func (ctx *Context) getProtectorOption(protectorDescriptor string) *ProtectorOption { -- cgit v1.2.3 From 6ffc9457945a9484d2757cc4b01de35426502d0a Mon Sep 17 00:00:00 2001 From: Eric Biggers Date: Sun, 15 Dec 2019 19:31:39 -0800 Subject: keyring: support filesystem keyring with v1 encryption policies 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. --- actions/context.go | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) (limited to 'actions/context.go') diff --git a/actions/context.go b/actions/context.go index 7703db5..f7e98cf 100644 --- a/actions/context.go +++ b/actions/context.go @@ -58,10 +58,11 @@ type Context struct { // modified after being loaded to customise parameters. Config *metadata.Config // Mount is the filesystem relative to which all Protectors and Policies - // are added, edited, removed, and applied. + // are added, edited, removed, and applied, and to which policies using + // the filesystem keyring are provisioned. Mount *filesystem.Mount - // TargetUser is the user for which protectors are created and to whose - // keyring policies are provisioned. + // TargetUser is the user for whom protectors are created, and to whose + // keyring policies using the user keyring are provisioned. TargetUser *user.User } @@ -148,8 +149,10 @@ func (ctx *Context) getService() string { func (ctx *Context) getKeyringOptions() *keyring.Options { return &keyring.Options{ - User: ctx.TargetUser, - Service: ctx.getService(), + Mount: ctx.Mount, + User: ctx.TargetUser, + Service: ctx.getService(), + UseFsKeyringForV1Policies: ctx.Config.GetUseFsKeyringForV1Policies(), } } -- cgit v1.2.3 From 42e0dfe85ec7a75a2fa30c417d57eae60b5a881d Mon Sep 17 00:00:00 2001 From: Eric Biggers Date: Sun, 15 Dec 2019 19:31:39 -0800 Subject: Keyring support for v2 encryption policies 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. --- actions/context.go | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'actions/context.go') diff --git a/actions/context.go b/actions/context.go index f7e98cf..f07f225 100644 --- a/actions/context.go +++ b/actions/context.go @@ -62,7 +62,9 @@ type Context struct { // the filesystem keyring are provisioned. Mount *filesystem.Mount // TargetUser is the user for whom protectors are created, and to whose - // keyring policies using the user keyring are provisioned. + // keyring policies using the user keyring are provisioned. It's also + // the user for whom the keys are claimed in the filesystem keyring when + // v2 policies are provisioned. TargetUser *user.User } -- cgit v1.2.3