2017-11-18 17:09:20 +01:00
|
|
|
/* SPDX-License-Identifier: LGPL-2.1+ */
|
2011-10-07 21:06:39 +02:00
|
|
|
|
|
|
|
#include <errno.h>
|
|
|
|
#include <fcntl.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
|
2013-12-10 18:01:10 +01:00
|
|
|
#include "sd-id128.h"
|
2015-10-24 22:58:24 +02:00
|
|
|
|
core: store the invocation ID in the per-service keyring
Let's store the invocation ID in the per-service keyring as a root-owned key,
with strict access rights. This has the advantage over the environment-based ID
passing that it also works from SUID binaries (as they key cannot be overidden
by unprivileged code starting them), in contrast to the secure_getenv() based
mode.
The invocation ID is now passed in three different ways to a service:
- As environment variable $INVOCATION_ID. This is easy to use, but may be
overriden by unprivileged code (which might be a bad or a good thing), which
means it's incompatible with SUID code (see above).
- As extended attribute on the service cgroup. This cannot be overriden by
unprivileged code, and may be queried safely from "outside" of a service.
However, it is incompatible with containers right now, as unprivileged
containers generally cannot set xattrs on cgroupfs.
- As "invocation_id" key in the kernel keyring. This has the benefit that the
key cannot be changed by unprivileged service code, and thus is safe to
access from SUID code (see above). But do note that service code can replace
the session keyring with a fresh one that lacks the key. However in that case
the key will not be owned by root, which is easily detectable. The keyring is
also incompatible with containers right now, as it is not properly namespace
aware (but this is being worked on), and thus most container managers mask
the keyring-related system calls.
Ideally we'd only have one way to pass the invocation ID, but the different
ways all have limitations. The invocation ID hookup in journald is currently
only available on the host but not in containers, due to the mentioned
limitations.
How to verify the new invocation ID in the keyring:
# systemd-run -t /bin/sh
Running as unit: run-rd917366c04f847b480d486017f7239d6.service
Press ^] three times within 1s to disconnect TTY.
# keyctl show
Session Keyring
680208392 --alswrv 0 0 keyring: _ses
250926536 ----s-rv 0 0 \_ user: invocation_id
# keyctl request user invocation_id
250926536
# keyctl read 250926536
16 bytes of data in key:
9c96317c ac64495a a42b9cd7 4f3ff96b
# echo $INVOCATION_ID
9c96317cac64495aa42b9cd74f3ff96b
# ^D
This creates a new transient service runnint a shell. Then verifies the
contents of the keyring, requests the invocation ID key, and reads its payload.
For comparison the invocation ID as passed via the environment variable is also
displayed.
2016-12-02 15:05:55 +01:00
|
|
|
#include "alloc-util.h"
|
2015-10-25 14:08:25 +01:00
|
|
|
#include "fd-util.h"
|
2015-11-16 22:09:36 +01:00
|
|
|
#include "hexdecoct.h"
|
2016-07-21 17:57:57 +02:00
|
|
|
#include "id128-util.h"
|
2015-10-25 14:08:25 +01:00
|
|
|
#include "io-util.h"
|
2016-11-17 17:07:46 +01:00
|
|
|
#include "khash.h"
|
2015-10-24 22:58:24 +02:00
|
|
|
#include "macro.h"
|
core: store the invocation ID in the per-service keyring
Let's store the invocation ID in the per-service keyring as a root-owned key,
with strict access rights. This has the advantage over the environment-based ID
passing that it also works from SUID binaries (as they key cannot be overidden
by unprivileged code starting them), in contrast to the secure_getenv() based
mode.
The invocation ID is now passed in three different ways to a service:
- As environment variable $INVOCATION_ID. This is easy to use, but may be
overriden by unprivileged code (which might be a bad or a good thing), which
means it's incompatible with SUID code (see above).
- As extended attribute on the service cgroup. This cannot be overriden by
unprivileged code, and may be queried safely from "outside" of a service.
However, it is incompatible with containers right now, as unprivileged
containers generally cannot set xattrs on cgroupfs.
- As "invocation_id" key in the kernel keyring. This has the benefit that the
key cannot be changed by unprivileged service code, and thus is safe to
access from SUID code (see above). But do note that service code can replace
the session keyring with a fresh one that lacks the key. However in that case
the key will not be owned by root, which is easily detectable. The keyring is
also incompatible with containers right now, as it is not properly namespace
aware (but this is being worked on), and thus most container managers mask
the keyring-related system calls.
Ideally we'd only have one way to pass the invocation ID, but the different
ways all have limitations. The invocation ID hookup in journald is currently
only available on the host but not in containers, due to the mentioned
limitations.
How to verify the new invocation ID in the keyring:
# systemd-run -t /bin/sh
Running as unit: run-rd917366c04f847b480d486017f7239d6.service
Press ^] three times within 1s to disconnect TTY.
# keyctl show
Session Keyring
680208392 --alswrv 0 0 keyring: _ses
250926536 ----s-rv 0 0 \_ user: invocation_id
# keyctl request user invocation_id
250926536
# keyctl read 250926536
16 bytes of data in key:
9c96317c ac64495a a42b9cd7 4f3ff96b
# echo $INVOCATION_ID
9c96317cac64495aa42b9cd74f3ff96b
# ^D
This creates a new transient service runnint a shell. Then verifies the
contents of the keyring, requests the invocation ID key, and reads its payload.
For comparison the invocation ID as passed via the environment variable is also
displayed.
2016-12-02 15:05:55 +01:00
|
|
|
#include "missing.h"
|
2015-04-10 22:27:10 +02:00
|
|
|
#include "random-util.h"
|
core: store the invocation ID in the per-service keyring
Let's store the invocation ID in the per-service keyring as a root-owned key,
with strict access rights. This has the advantage over the environment-based ID
passing that it also works from SUID binaries (as they key cannot be overidden
by unprivileged code starting them), in contrast to the secure_getenv() based
mode.
The invocation ID is now passed in three different ways to a service:
- As environment variable $INVOCATION_ID. This is easy to use, but may be
overriden by unprivileged code (which might be a bad or a good thing), which
means it's incompatible with SUID code (see above).
- As extended attribute on the service cgroup. This cannot be overriden by
unprivileged code, and may be queried safely from "outside" of a service.
However, it is incompatible with containers right now, as unprivileged
containers generally cannot set xattrs on cgroupfs.
- As "invocation_id" key in the kernel keyring. This has the benefit that the
key cannot be changed by unprivileged service code, and thus is safe to
access from SUID code (see above). But do note that service code can replace
the session keyring with a fresh one that lacks the key. However in that case
the key will not be owned by root, which is easily detectable. The keyring is
also incompatible with containers right now, as it is not properly namespace
aware (but this is being worked on), and thus most container managers mask
the keyring-related system calls.
Ideally we'd only have one way to pass the invocation ID, but the different
ways all have limitations. The invocation ID hookup in journald is currently
only available on the host but not in containers, due to the mentioned
limitations.
How to verify the new invocation ID in the keyring:
# systemd-run -t /bin/sh
Running as unit: run-rd917366c04f847b480d486017f7239d6.service
Press ^] three times within 1s to disconnect TTY.
# keyctl show
Session Keyring
680208392 --alswrv 0 0 keyring: _ses
250926536 ----s-rv 0 0 \_ user: invocation_id
# keyctl request user invocation_id
250926536
# keyctl read 250926536
16 bytes of data in key:
9c96317c ac64495a a42b9cd7 4f3ff96b
# echo $INVOCATION_ID
9c96317cac64495aa42b9cd74f3ff96b
# ^D
This creates a new transient service runnint a shell. Then verifies the
contents of the keyring, requests the invocation ID key, and reads its payload.
For comparison the invocation ID as passed via the environment variable is also
displayed.
2016-12-02 15:05:55 +01:00
|
|
|
#include "user-util.h"
|
2015-10-24 22:58:24 +02:00
|
|
|
#include "util.h"
|
2011-10-07 21:06:39 +02:00
|
|
|
|
2015-09-17 01:22:10 +02:00
|
|
|
_public_ char *sd_id128_to_string(sd_id128_t id, char s[SD_ID128_STRING_MAX]) {
|
2011-10-07 21:06:39 +02:00
|
|
|
unsigned n;
|
|
|
|
|
2013-12-02 22:42:01 +01:00
|
|
|
assert_return(s, NULL);
|
2011-10-07 21:06:39 +02:00
|
|
|
|
|
|
|
for (n = 0; n < 16; n++) {
|
|
|
|
s[n*2] = hexchar(id.bytes[n] >> 4);
|
|
|
|
s[n*2+1] = hexchar(id.bytes[n] & 0xF);
|
|
|
|
}
|
|
|
|
|
|
|
|
s[32] = 0;
|
|
|
|
|
|
|
|
return s;
|
|
|
|
}
|
|
|
|
|
2013-04-29 23:39:12 +02:00
|
|
|
_public_ int sd_id128_from_string(const char s[], sd_id128_t *ret) {
|
|
|
|
unsigned n, i;
|
2011-10-07 21:06:39 +02:00
|
|
|
sd_id128_t t;
|
2013-04-29 23:39:12 +02:00
|
|
|
bool is_guid = false;
|
2011-10-07 21:06:39 +02:00
|
|
|
|
2013-12-02 22:42:01 +01:00
|
|
|
assert_return(s, -EINVAL);
|
2011-10-07 21:06:39 +02:00
|
|
|
|
2013-04-29 23:39:12 +02:00
|
|
|
for (n = 0, i = 0; n < 16;) {
|
2011-10-07 21:06:39 +02:00
|
|
|
int a, b;
|
|
|
|
|
2013-04-29 23:39:12 +02:00
|
|
|
if (s[i] == '-') {
|
|
|
|
/* Is this a GUID? Then be nice, and skip over
|
|
|
|
* the dashes */
|
|
|
|
|
|
|
|
if (i == 8)
|
|
|
|
is_guid = true;
|
2017-09-28 10:17:04 +02:00
|
|
|
else if (IN_SET(i, 13, 18, 23)) {
|
2013-04-29 23:39:12 +02:00
|
|
|
if (!is_guid)
|
|
|
|
return -EINVAL;
|
|
|
|
} else
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
i++;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
a = unhexchar(s[i++]);
|
2011-10-07 21:06:39 +02:00
|
|
|
if (a < 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2013-04-29 23:39:12 +02:00
|
|
|
b = unhexchar(s[i++]);
|
2011-10-07 21:06:39 +02:00
|
|
|
if (b < 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2013-04-29 23:39:12 +02:00
|
|
|
t.bytes[n++] = (a << 4) | b;
|
2011-10-07 21:06:39 +02:00
|
|
|
}
|
|
|
|
|
2013-04-29 23:39:12 +02:00
|
|
|
if (i != (is_guid ? 36 : 32))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (s[i] != 0)
|
2011-10-07 21:06:39 +02:00
|
|
|
return -EINVAL;
|
|
|
|
|
2016-07-21 20:23:51 +02:00
|
|
|
if (ret)
|
|
|
|
*ret = t;
|
2011-10-07 21:06:39 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-01-03 20:58:07 +01:00
|
|
|
_public_ int sd_id128_get_machine(sd_id128_t *ret) {
|
2016-07-21 17:57:57 +02:00
|
|
|
static thread_local sd_id128_t saved_machine_id = {};
|
2015-03-10 02:23:53 +01:00
|
|
|
int r;
|
2011-10-07 21:06:39 +02:00
|
|
|
|
2013-12-02 22:42:01 +01:00
|
|
|
assert_return(ret, -EINVAL);
|
2012-01-03 20:58:07 +01:00
|
|
|
|
2016-07-21 17:57:57 +02:00
|
|
|
if (sd_id128_is_null(saved_machine_id)) {
|
|
|
|
r = id128_read("/etc/machine-id", ID128_PLAIN, &saved_machine_id);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
2011-10-07 21:06:39 +02:00
|
|
|
|
2016-07-21 17:57:57 +02:00
|
|
|
if (sd_id128_is_null(saved_machine_id))
|
2018-05-16 13:55:12 +02:00
|
|
|
return -ENOMEDIUM;
|
2011-10-07 21:06:39 +02:00
|
|
|
}
|
|
|
|
|
2016-07-21 17:57:57 +02:00
|
|
|
*ret = saved_machine_id;
|
2011-10-07 21:06:39 +02:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-01-03 20:58:07 +01:00
|
|
|
_public_ int sd_id128_get_boot(sd_id128_t *ret) {
|
2016-07-21 17:57:57 +02:00
|
|
|
static thread_local sd_id128_t saved_boot_id = {};
|
2015-03-10 02:23:53 +01:00
|
|
|
int r;
|
2011-10-07 21:06:39 +02:00
|
|
|
|
2013-12-02 22:42:01 +01:00
|
|
|
assert_return(ret, -EINVAL);
|
2012-01-03 20:58:07 +01:00
|
|
|
|
2016-07-21 17:57:57 +02:00
|
|
|
if (sd_id128_is_null(saved_boot_id)) {
|
|
|
|
r = id128_read("/proc/sys/kernel/random/boot_id", ID128_UUID, &saved_boot_id);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
2011-10-07 21:06:39 +02:00
|
|
|
}
|
|
|
|
|
2016-07-21 17:57:57 +02:00
|
|
|
*ret = saved_boot_id;
|
|
|
|
return 0;
|
|
|
|
}
|
2011-10-07 21:06:39 +02:00
|
|
|
|
core: store the invocation ID in the per-service keyring
Let's store the invocation ID in the per-service keyring as a root-owned key,
with strict access rights. This has the advantage over the environment-based ID
passing that it also works from SUID binaries (as they key cannot be overidden
by unprivileged code starting them), in contrast to the secure_getenv() based
mode.
The invocation ID is now passed in three different ways to a service:
- As environment variable $INVOCATION_ID. This is easy to use, but may be
overriden by unprivileged code (which might be a bad or a good thing), which
means it's incompatible with SUID code (see above).
- As extended attribute on the service cgroup. This cannot be overriden by
unprivileged code, and may be queried safely from "outside" of a service.
However, it is incompatible with containers right now, as unprivileged
containers generally cannot set xattrs on cgroupfs.
- As "invocation_id" key in the kernel keyring. This has the benefit that the
key cannot be changed by unprivileged service code, and thus is safe to
access from SUID code (see above). But do note that service code can replace
the session keyring with a fresh one that lacks the key. However in that case
the key will not be owned by root, which is easily detectable. The keyring is
also incompatible with containers right now, as it is not properly namespace
aware (but this is being worked on), and thus most container managers mask
the keyring-related system calls.
Ideally we'd only have one way to pass the invocation ID, but the different
ways all have limitations. The invocation ID hookup in journald is currently
only available on the host but not in containers, due to the mentioned
limitations.
How to verify the new invocation ID in the keyring:
# systemd-run -t /bin/sh
Running as unit: run-rd917366c04f847b480d486017f7239d6.service
Press ^] three times within 1s to disconnect TTY.
# keyctl show
Session Keyring
680208392 --alswrv 0 0 keyring: _ses
250926536 ----s-rv 0 0 \_ user: invocation_id
# keyctl request user invocation_id
250926536
# keyctl read 250926536
16 bytes of data in key:
9c96317c ac64495a a42b9cd7 4f3ff96b
# echo $INVOCATION_ID
9c96317cac64495aa42b9cd74f3ff96b
# ^D
This creates a new transient service runnint a shell. Then verifies the
contents of the keyring, requests the invocation ID key, and reads its payload.
For comparison the invocation ID as passed via the environment variable is also
displayed.
2016-12-02 15:05:55 +01:00
|
|
|
static int get_invocation_from_keyring(sd_id128_t *ret) {
|
|
|
|
|
|
|
|
_cleanup_free_ char *description = NULL;
|
|
|
|
char *d, *p, *g, *u, *e;
|
|
|
|
unsigned long perms;
|
|
|
|
key_serial_t key;
|
|
|
|
size_t sz = 256;
|
|
|
|
uid_t uid;
|
|
|
|
gid_t gid;
|
|
|
|
int r, c;
|
|
|
|
|
|
|
|
#define MAX_PERMS ((unsigned long) (KEY_POS_VIEW|KEY_POS_READ|KEY_POS_SEARCH| \
|
|
|
|
KEY_USR_VIEW|KEY_USR_READ|KEY_USR_SEARCH))
|
|
|
|
|
|
|
|
assert(ret);
|
|
|
|
|
|
|
|
key = request_key("user", "invocation_id", NULL, 0);
|
|
|
|
if (key == -1) {
|
|
|
|
/* Keyring support not available? No invocation key stored? */
|
|
|
|
if (IN_SET(errno, ENOSYS, ENOKEY))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return -errno;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
description = new(char, sz);
|
|
|
|
if (!description)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
c = keyctl(KEYCTL_DESCRIBE, key, (unsigned long) description, sz, 0);
|
|
|
|
if (c < 0)
|
|
|
|
return -errno;
|
|
|
|
|
|
|
|
if ((size_t) c <= sz)
|
|
|
|
break;
|
|
|
|
|
|
|
|
sz = c;
|
|
|
|
free(description);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The kernel returns a final NUL in the string, verify that. */
|
|
|
|
assert(description[c-1] == 0);
|
|
|
|
|
|
|
|
/* Chop off the final description string */
|
|
|
|
d = strrchr(description, ';');
|
|
|
|
if (!d)
|
|
|
|
return -EIO;
|
|
|
|
*d = 0;
|
|
|
|
|
|
|
|
/* Look for the permissions */
|
|
|
|
p = strrchr(description, ';');
|
|
|
|
if (!p)
|
|
|
|
return -EIO;
|
|
|
|
|
|
|
|
errno = 0;
|
|
|
|
perms = strtoul(p + 1, &e, 16);
|
|
|
|
if (errno > 0)
|
|
|
|
return -errno;
|
|
|
|
if (e == p + 1) /* Read at least one character */
|
|
|
|
return -EIO;
|
|
|
|
if (e != d) /* Must reached the end */
|
|
|
|
return -EIO;
|
|
|
|
|
|
|
|
if ((perms & ~MAX_PERMS) != 0)
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
*p = 0;
|
|
|
|
|
|
|
|
/* Look for the group ID */
|
|
|
|
g = strrchr(description, ';');
|
|
|
|
if (!g)
|
|
|
|
return -EIO;
|
|
|
|
r = parse_gid(g + 1, &gid);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
if (gid != 0)
|
|
|
|
return -EPERM;
|
|
|
|
*g = 0;
|
|
|
|
|
|
|
|
/* Look for the user ID */
|
|
|
|
u = strrchr(description, ';');
|
|
|
|
if (!u)
|
|
|
|
return -EIO;
|
|
|
|
r = parse_uid(u + 1, &uid);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
if (uid != 0)
|
|
|
|
return -EPERM;
|
|
|
|
|
|
|
|
c = keyctl(KEYCTL_READ, key, (unsigned long) ret, sizeof(sd_id128_t), 0);
|
|
|
|
if (c < 0)
|
|
|
|
return -errno;
|
|
|
|
if (c != sizeof(sd_id128_t))
|
|
|
|
return -EIO;
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2016-08-30 23:18:46 +02:00
|
|
|
_public_ int sd_id128_get_invocation(sd_id128_t *ret) {
|
|
|
|
static thread_local sd_id128_t saved_invocation_id = {};
|
|
|
|
int r;
|
|
|
|
|
|
|
|
assert_return(ret, -EINVAL);
|
|
|
|
|
|
|
|
if (sd_id128_is_null(saved_invocation_id)) {
|
|
|
|
|
core: store the invocation ID in the per-service keyring
Let's store the invocation ID in the per-service keyring as a root-owned key,
with strict access rights. This has the advantage over the environment-based ID
passing that it also works from SUID binaries (as they key cannot be overidden
by unprivileged code starting them), in contrast to the secure_getenv() based
mode.
The invocation ID is now passed in three different ways to a service:
- As environment variable $INVOCATION_ID. This is easy to use, but may be
overriden by unprivileged code (which might be a bad or a good thing), which
means it's incompatible with SUID code (see above).
- As extended attribute on the service cgroup. This cannot be overriden by
unprivileged code, and may be queried safely from "outside" of a service.
However, it is incompatible with containers right now, as unprivileged
containers generally cannot set xattrs on cgroupfs.
- As "invocation_id" key in the kernel keyring. This has the benefit that the
key cannot be changed by unprivileged service code, and thus is safe to
access from SUID code (see above). But do note that service code can replace
the session keyring with a fresh one that lacks the key. However in that case
the key will not be owned by root, which is easily detectable. The keyring is
also incompatible with containers right now, as it is not properly namespace
aware (but this is being worked on), and thus most container managers mask
the keyring-related system calls.
Ideally we'd only have one way to pass the invocation ID, but the different
ways all have limitations. The invocation ID hookup in journald is currently
only available on the host but not in containers, due to the mentioned
limitations.
How to verify the new invocation ID in the keyring:
# systemd-run -t /bin/sh
Running as unit: run-rd917366c04f847b480d486017f7239d6.service
Press ^] three times within 1s to disconnect TTY.
# keyctl show
Session Keyring
680208392 --alswrv 0 0 keyring: _ses
250926536 ----s-rv 0 0 \_ user: invocation_id
# keyctl request user invocation_id
250926536
# keyctl read 250926536
16 bytes of data in key:
9c96317c ac64495a a42b9cd7 4f3ff96b
# echo $INVOCATION_ID
9c96317cac64495aa42b9cd74f3ff96b
# ^D
This creates a new transient service runnint a shell. Then verifies the
contents of the keyring, requests the invocation ID key, and reads its payload.
For comparison the invocation ID as passed via the environment variable is also
displayed.
2016-12-02 15:05:55 +01:00
|
|
|
/* We first try to read the invocation ID from the kernel keyring. This has the benefit that it is not
|
|
|
|
* fakeable by unprivileged code. If the information is not available in the keyring, we use
|
|
|
|
* $INVOCATION_ID but ignore the data if our process was called by less privileged code
|
|
|
|
* (i.e. secure_getenv() instead of getenv()).
|
|
|
|
*
|
|
|
|
* The kernel keyring is only relevant for system services (as for user services we don't store the
|
|
|
|
* invocation ID in the keyring, as there'd be no trust benefit in that). The environment variable is
|
|
|
|
* primarily relevant for user services, and sufficiently safe as no privilege boundary is involved. */
|
2016-08-30 23:18:46 +02:00
|
|
|
|
core: store the invocation ID in the per-service keyring
Let's store the invocation ID in the per-service keyring as a root-owned key,
with strict access rights. This has the advantage over the environment-based ID
passing that it also works from SUID binaries (as they key cannot be overidden
by unprivileged code starting them), in contrast to the secure_getenv() based
mode.
The invocation ID is now passed in three different ways to a service:
- As environment variable $INVOCATION_ID. This is easy to use, but may be
overriden by unprivileged code (which might be a bad or a good thing), which
means it's incompatible with SUID code (see above).
- As extended attribute on the service cgroup. This cannot be overriden by
unprivileged code, and may be queried safely from "outside" of a service.
However, it is incompatible with containers right now, as unprivileged
containers generally cannot set xattrs on cgroupfs.
- As "invocation_id" key in the kernel keyring. This has the benefit that the
key cannot be changed by unprivileged service code, and thus is safe to
access from SUID code (see above). But do note that service code can replace
the session keyring with a fresh one that lacks the key. However in that case
the key will not be owned by root, which is easily detectable. The keyring is
also incompatible with containers right now, as it is not properly namespace
aware (but this is being worked on), and thus most container managers mask
the keyring-related system calls.
Ideally we'd only have one way to pass the invocation ID, but the different
ways all have limitations. The invocation ID hookup in journald is currently
only available on the host but not in containers, due to the mentioned
limitations.
How to verify the new invocation ID in the keyring:
# systemd-run -t /bin/sh
Running as unit: run-rd917366c04f847b480d486017f7239d6.service
Press ^] three times within 1s to disconnect TTY.
# keyctl show
Session Keyring
680208392 --alswrv 0 0 keyring: _ses
250926536 ----s-rv 0 0 \_ user: invocation_id
# keyctl request user invocation_id
250926536
# keyctl read 250926536
16 bytes of data in key:
9c96317c ac64495a a42b9cd7 4f3ff96b
# echo $INVOCATION_ID
9c96317cac64495aa42b9cd74f3ff96b
# ^D
This creates a new transient service runnint a shell. Then verifies the
contents of the keyring, requests the invocation ID key, and reads its payload.
For comparison the invocation ID as passed via the environment variable is also
displayed.
2016-12-02 15:05:55 +01:00
|
|
|
r = get_invocation_from_keyring(&saved_invocation_id);
|
2016-08-30 23:18:46 +02:00
|
|
|
if (r < 0)
|
|
|
|
return r;
|
core: store the invocation ID in the per-service keyring
Let's store the invocation ID in the per-service keyring as a root-owned key,
with strict access rights. This has the advantage over the environment-based ID
passing that it also works from SUID binaries (as they key cannot be overidden
by unprivileged code starting them), in contrast to the secure_getenv() based
mode.
The invocation ID is now passed in three different ways to a service:
- As environment variable $INVOCATION_ID. This is easy to use, but may be
overriden by unprivileged code (which might be a bad or a good thing), which
means it's incompatible with SUID code (see above).
- As extended attribute on the service cgroup. This cannot be overriden by
unprivileged code, and may be queried safely from "outside" of a service.
However, it is incompatible with containers right now, as unprivileged
containers generally cannot set xattrs on cgroupfs.
- As "invocation_id" key in the kernel keyring. This has the benefit that the
key cannot be changed by unprivileged service code, and thus is safe to
access from SUID code (see above). But do note that service code can replace
the session keyring with a fresh one that lacks the key. However in that case
the key will not be owned by root, which is easily detectable. The keyring is
also incompatible with containers right now, as it is not properly namespace
aware (but this is being worked on), and thus most container managers mask
the keyring-related system calls.
Ideally we'd only have one way to pass the invocation ID, but the different
ways all have limitations. The invocation ID hookup in journald is currently
only available on the host but not in containers, due to the mentioned
limitations.
How to verify the new invocation ID in the keyring:
# systemd-run -t /bin/sh
Running as unit: run-rd917366c04f847b480d486017f7239d6.service
Press ^] three times within 1s to disconnect TTY.
# keyctl show
Session Keyring
680208392 --alswrv 0 0 keyring: _ses
250926536 ----s-rv 0 0 \_ user: invocation_id
# keyctl request user invocation_id
250926536
# keyctl read 250926536
16 bytes of data in key:
9c96317c ac64495a a42b9cd7 4f3ff96b
# echo $INVOCATION_ID
9c96317cac64495aa42b9cd74f3ff96b
# ^D
This creates a new transient service runnint a shell. Then verifies the
contents of the keyring, requests the invocation ID key, and reads its payload.
For comparison the invocation ID as passed via the environment variable is also
displayed.
2016-12-02 15:05:55 +01:00
|
|
|
|
|
|
|
if (r == 0) {
|
|
|
|
const char *e;
|
|
|
|
|
|
|
|
e = secure_getenv("INVOCATION_ID");
|
|
|
|
if (!e)
|
|
|
|
return -ENXIO;
|
|
|
|
|
|
|
|
r = sd_id128_from_string(e, &saved_invocation_id);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
}
|
2016-08-30 23:18:46 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
*ret = saved_invocation_id;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-07-21 17:57:57 +02:00
|
|
|
static sd_id128_t make_v4_uuid(sd_id128_t id) {
|
|
|
|
/* Stolen from generate_random_uuid() of drivers/char/random.c
|
|
|
|
* in the kernel sources */
|
2011-10-07 21:06:39 +02:00
|
|
|
|
2016-07-21 17:57:57 +02:00
|
|
|
/* Set UUID version to 4 --- truly random generation */
|
|
|
|
id.bytes[6] = (id.bytes[6] & 0x0F) | 0x40;
|
2011-10-07 21:06:39 +02:00
|
|
|
|
2016-07-21 17:57:57 +02:00
|
|
|
/* Set the UUID variant to DCE */
|
|
|
|
id.bytes[8] = (id.bytes[8] & 0x3F) | 0x80;
|
2011-10-07 21:06:39 +02:00
|
|
|
|
2016-07-21 17:57:57 +02:00
|
|
|
return id;
|
2011-10-07 21:06:39 +02:00
|
|
|
}
|
|
|
|
|
2012-01-03 20:58:07 +01:00
|
|
|
_public_ int sd_id128_randomize(sd_id128_t *ret) {
|
2011-10-07 21:06:39 +02:00
|
|
|
sd_id128_t t;
|
2014-02-19 17:50:15 +01:00
|
|
|
int r;
|
2011-10-07 21:06:39 +02:00
|
|
|
|
2013-12-02 22:42:01 +01:00
|
|
|
assert_return(ret, -EINVAL);
|
2011-10-07 21:06:39 +02:00
|
|
|
|
basic/random-util: do not fall back to /dev/urandom if getrandom() returns short
During early boot, we'd call getrandom(), and immediately fall back to
reading from /dev/urandom unless we got the full requested number of bytes.
Those two sources are the same, so the most likely result is /dev/urandom
producing some pseudorandom numbers for us, complaining widely on the way.
Let's change our behaviour to be more conservative:
- if the numbers are only used to initialize a hash table, a short read is OK,
we don't really care if we get the first part of the seed truly random and
then some pseudorandom bytes. So just do that and return "success".
- if getrandom() returns -EAGAIN, fall back to rand() instead of querying
/dev/urandom again.
The idea with those two changes is to avoid generating a warning about
reading from an /dev/urandom when the kernel doesn't have enough entropy.
- only in the cases where we really need to make the best effort possible
(sd_id128_randomize and firstboot password hashing), fall back to
/dev/urandom.
When calling getrandom(), drop the checks whether the argument fits in an int —
getrandom() should do that for us already, and we call it with small arguments
only anyway.
Note that this does not really change the (relatively high) number of random
bytes we request from the kernel. On my laptop, during boot, PID 1 and all
other processes using this code through libsystemd request:
74780 bytes with high_quality_required == false
464 bytes with high_quality_required == true
and it does not eliminate reads from /dev/urandom completely. If the kernel was
short on entropy and getrandom() would fail, we would fall back to /dev/urandom
for those 464 bytes.
When falling back to /dev/urandom, don't lose the short read we already got,
and just read the remaining bytes.
If getrandom() syscall is not available, we fall back to /dev/urandom same
as before.
Fixes #4167 (possibly partially, let's see).
2017-06-25 23:09:05 +02:00
|
|
|
r = acquire_random_bytes(&t, sizeof t, true);
|
2014-02-19 17:50:15 +01:00
|
|
|
if (r < 0)
|
|
|
|
return r;
|
2011-10-07 21:06:39 +02:00
|
|
|
|
|
|
|
/* Turn this into a valid v4 UUID, to be nice. Note that we
|
|
|
|
* only guarantee this for newly generated UUIDs, not for
|
2014-12-10 20:00:09 +01:00
|
|
|
* pre-existing ones. */
|
2011-10-07 21:06:39 +02:00
|
|
|
|
2012-01-07 01:37:39 +01:00
|
|
|
*ret = make_v4_uuid(t);
|
2011-10-07 21:06:39 +02:00
|
|
|
return 0;
|
|
|
|
}
|
2016-11-17 17:07:46 +01:00
|
|
|
|
2018-10-02 14:25:24 +02:00
|
|
|
static int get_app_specific(sd_id128_t base, sd_id128_t app_id, sd_id128_t *ret) {
|
2016-11-17 17:07:46 +01:00
|
|
|
_cleanup_(khash_unrefp) khash *h = NULL;
|
2018-10-02 14:25:24 +02:00
|
|
|
sd_id128_t result;
|
2016-11-17 17:07:46 +01:00
|
|
|
const void *p;
|
|
|
|
int r;
|
|
|
|
|
2018-10-02 14:25:24 +02:00
|
|
|
assert(ret);
|
2016-11-17 17:07:46 +01:00
|
|
|
|
2018-10-02 14:25:24 +02:00
|
|
|
r = khash_new_with_key(&h, "hmac(sha256)", &base, sizeof(base));
|
2016-11-17 17:07:46 +01:00
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
r = khash_put(h, &app_id, sizeof(app_id));
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
r = khash_digest_data(h, &p);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
/* We chop off the trailing 16 bytes */
|
|
|
|
memcpy(&result, p, MIN(khash_get_size(h), sizeof(result)));
|
|
|
|
|
|
|
|
*ret = make_v4_uuid(result);
|
|
|
|
return 0;
|
|
|
|
}
|
2018-10-02 14:25:24 +02:00
|
|
|
|
|
|
|
_public_ int sd_id128_get_machine_app_specific(sd_id128_t app_id, sd_id128_t *ret) {
|
|
|
|
sd_id128_t id;
|
|
|
|
int r;
|
|
|
|
|
|
|
|
assert_return(ret, -EINVAL);
|
|
|
|
|
|
|
|
r = sd_id128_get_machine(&id);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
return get_app_specific(id, app_id, ret);
|
|
|
|
}
|
|
|
|
|
|
|
|
_public_ int sd_id128_get_boot_app_specific(sd_id128_t app_id, sd_id128_t *ret) {
|
|
|
|
sd_id128_t id;
|
|
|
|
int r;
|
|
|
|
|
|
|
|
assert_return(ret, -EINVAL);
|
|
|
|
|
|
|
|
r = sd_id128_get_boot(&id);
|
|
|
|
if (r < 0)
|
|
|
|
return r;
|
|
|
|
|
|
|
|
return get_app_specific(id, app_id, ret);
|
|
|
|
}
|