lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 12 Jul 2022 08:35:19 -0400
From:   Benjamin Coddington <bcodding@...hat.com>
To:     David Howells <dhowells@...hat.com>, linux-kernel@...r.kernel.org
Cc:     ebiederm@...ssion.com, Ian Kent <raven@...maw.net>,
        Trond Myklebust <trond.myklebust@...merspace.com>,
        linux-nfs@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: [RFC PATCH 0/2] Keyagents: another call_usermodehelper approach for namespaces

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

-- 
// SPDX-License-Identifier: GPL-2.0-only
/* ka_simple.c: userspace keyagent example
 *
 * Copyright (C) 2022 Red Hat Inc. All Rights Reserved.
 * Written by Benjamin Coddington (bcodding@...hat.com)
 *
 * This programs registers a simple keyagent for user keys that will handle
 * requests from the kernel keyagent, and instantiate keys that have
 * callout_info == "test_callout_info".
 */
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <err.h>
#include <errno.h>
#include <stdlib.h>
#include <signal.h>
#include <linux/types.h>
#include <keyutils.h>
#include <sys/signalfd.h>

int ka_sig_fd = 0;
key_serial_t ka_key_serial;
__be16 ka_signal;

/* Setup a signalfd masked to SIGRTMIN + 1 */
void ka_sig_setup()
{
	int ret;
	sigset_t mask;

	/* Which realtime signal are we using? */
	ka_signal = SIGRTMIN + 1;

	sigemptyset(&mask);
	sigaddset(&mask, ka_signal);

	ret = sigprocmask(SIG_BLOCK, &mask, NULL);
	if (ret != 0)
		err(ret, "rt_sigprocmask");

	ka_sig_fd = signalfd(-1, &mask, 0);
	if (ka_sig_fd == -1)
		err(ret, "signalfd");
}

/* Register this process as a keyagent for user keys to be notified by
 * signal number SIGRTMIN + 1 by creating a keyagent key with a description
 * of "user", and payload of SIGRTMIN + 1 */
void ka_register()
{
	printf("Registering as keyagent for user keys with signal %d\n", ka_signal);
	/* The kernel will place authorization keys on our process keyring.
	 * Make sure we have a process keyring: */
	keyctl_get_keyring_ID(KEY_SPEC_PROCESS_KEYRING, 1);
	ka_key_serial = add_key("keyagent", "user", &ka_signal, sizeof(unsigned int), KEY_SPEC_SESSION_KEYRING);

	if (ka_key_serial == -1)
		err(errno, "add_key");

	/* Permissions for the keyagent's key: */
	keyctl_setperm(ka_key_serial, KEY_USR_ALL);
}

/* Handle kernel request_key().  The serial number of the key is the int
 * passed in the realtime signal */
int ka_request_key(key_serial_t key) {
	int ret, ntype, dpos, n;
	char *buf_type_desc, *key_type, *key_desc;
	void *callout;

	printf("ka_request_key %d\n", key);

	ret = keyctl_assume_authority(key);
	if (ret < 0) {
		warn("failed to assume authority over key %d (%m)\n", key);
		goto out;
	}

	ret = keyctl_describe_alloc(key, &buf_type_desc);
	if (ret < 0) {
		warn("key %d inaccessible (%m)\n", key);
		goto out;
	}

	printf("Key descriptor: \"%s\"\n", buf_type_desc);

	/* Shamelessly copied from libkeyutils/request_key.c: */
	ntype = -1;
	dpos = -1;

	n = sscanf(buf_type_desc, "%*[^;]%n;%*d;%*d;%x;%n", &ntype, &n, &dpos);
	if (n != 1)
		printf("Failed to parse key description\n");

	key_type = buf_type_desc;
	key_type[ntype] = 0;
	key_desc = buf_type_desc + dpos;

	ret = keyctl_read_alloc(KEY_SPEC_REQKEY_AUTH_KEY, &callout);
	if (ret < 0) {
		warn("failed to retrieve callout info (%m)\n");
		goto out_free_type;
	}

	if (strcmp(buf_type_desc, "user") == 0 && strcmp(callout, "test_callout_info") == 0) {
		keyctl_instantiate(key, "keyagent_payload", sizeof("keyagent_payload"), KEY_SPEC_SESSION_KEYRING);
		printf("instantiated key %d with payload \"keyagent_payload\" on session keyring\n", key);
	} else {
		keyctl_reject(key, 10, EKEYREJECTED, KEY_SPEC_SESSION_KEYRING);
		printf("this keyagent only instantiates user keys with callout \"test_callout_info\"\n");
	}

	/* De-assume the authority (for now) */	
	ret = keyctl_assume_authority(0);
	free(callout);
	
out_free_type:
	free(buf_type_desc);
out:
	return ret;
}

/* Handle signals from our signalfd, dispatch ka_request_key() */
int ka_process()
{
	struct signalfd_siginfo fdsi;
	ssize_t size;

	for (;;) {
		size = read(ka_sig_fd, &fdsi, sizeof(struct signalfd_siginfo));
		if (size != sizeof(struct signalfd_siginfo))
			err(EINVAL, "reading signal_fd");

		if (ka_request_key(fdsi.ssi_int))
			break;
	}
}

int main(int argc, char **argv)
{
	ka_sig_setup();
	ka_register();

	printf("Registered as keyagent with key %d\n", ka_key_serial);
	printf("Subscribe to this keyagent by linking it into your session keyring with:\n\tkeyctl link %d @s\n", ka_key_serial);
	printf("then, you can send a request to this agent with:\n\tkeyctl request2 user <description> \"test_callout_info\"\n");

	ka_process();
}

--
2.31.1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ