From patchwork Tue Jul 12 12:35:19 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Benjamin Coddington X-Patchwork-Id: 12914902 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0C227C43334 for ; Tue, 12 Jul 2022 12:35:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230230AbiGLMf1 (ORCPT ); Tue, 12 Jul 2022 08:35:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52314 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231259AbiGLMf0 (ORCPT ); Tue, 12 Jul 2022 08:35:26 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 9A3082B619 for ; Tue, 12 Jul 2022 05:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1657629323; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=ZRNqvwEkQjWUz9SudAZmar3Unjg5boMD/ciY51IuWI8=; b=gB4ZcsAHK9jDfveQQ8QiT3AK3hrjD50kCmCQSL9jXN/+8m/jvrMYRjCLWbTr7vQOqEvOqS zsBehL6VCCYtf7X4TX/xerdtZ6sAx3mIJJwZHJDEdm+sLV0iAa0k9bgPbA5ea4sv80e6om /j72e0KzBPYYFBL1CdkO8tjNVvIcwV8= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-454-Fr7dWCPbPbS7hKwO1fVVSw-1; Tue, 12 Jul 2022 08:35:22 -0400 X-MC-Unique: Fr7dWCPbPbS7hKwO1fVVSw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0FAF02919EBB; Tue, 12 Jul 2022 12:35:22 +0000 (UTC) Received: from bcodding.csb (unknown [10.22.48.8]) by smtp.corp.redhat.com (Postfix) with ESMTP id CDAE82026D64; Tue, 12 Jul 2022 12:35:21 +0000 (UTC) Received: by bcodding.csb (Postfix, from userid 24008) id 50C4A10C30E0; Tue, 12 Jul 2022 08:35:21 -0400 (EDT) From: Benjamin Coddington To: David Howells , linux-kernel@vger.kernel.org Cc: ebiederm@xmission.com, Ian Kent , Trond Myklebust , linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: [RFC PATCH 0/2] Keyagents: another call_usermodehelper approach for namespaces Date: Tue, 12 Jul 2022 08:35:19 -0400 Message-Id: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org A persistent unsolved problem exists: how can the kernel find and/or create the appropriate "container" within which to execute a userspace program to construct keys or satisfy users of call_usermodehelper()? I believe the latest serious attempt to solve this problem was David's "Make containers kernel objects": https://lore.kernel.org/lkml/149547014649.10599.12025037906646164347.stgit@warthog.procyon.org.uk/ Over in NFS' space, we've most recently pondered this issue while looking at ways to pass a kernel socket to userspace in order to handle TLS events: https://lore.kernel.org/linux-nfs/E2BF9CFF-9361-400B-BDEE-CF5E0AFDCA63@redhat.com/ The problem is that containers are not kernel objects, rather a collection of namespaces, cgroups, etc. Attempts at making the kernel aware of containers have been mired in discussion and problems. It has been suggested that the best representation of a "container" from the kernel's perspective is a process. Keyagents are processes represented by a key. If a keyagent's key is linked to a session_keyring, it can be sent a realtime signal when a calling process requests a matching key_type. That signal will dispatch the process to construct the desired key within the keyagent process context. Keyagents are similar to ssh-agents. To use a keyagent, one must execute a keyagent process in the desired context, and then link the keyagent's key onto other process' session_keyrings. This method of linking keyagent keys to session_keyrings can be used to construct the various mappings of callers to keyagents that containers may need. A single keyagent process can answer request-key upcalls across container boundaries, or upcalls can be restricted to specific containers. I'm aware that building on realtime signals may not be a popular choice, but using realtime signals makes this work simple and ensures delivery. Realtime signals are able to convey everything needed to construct keys in userspace: the under-construction key's serial number. This work is not complete; it has security implications, it needs documentation, it has not been reviewed by anyone. Thanks for reading this RFC. I wish to collect criticism and validate this approach. Below the diffstat in this message is an example userspace program to answer keyagent requests for user keys. It can be compiled with: gcc -lkeyutils -o ka_simple ka_simple.c Benjamin Coddington (2): KEYS: Add key_type keyagent KEYS: Add keyagent request_key include/uapi/asm-generic/siginfo.h | 1 + security/keys/Kconfig | 9 ++ security/keys/Makefile | 1 + security/keys/internal.h | 4 + security/keys/keyagent.c | 158 +++++++++++++++++++++++++++++ security/keys/request_key.c | 9 ++ 6 files changed, 182 insertions(+) create mode 100644 security/keys/keyagent.c