[PATCH v2 00/10] Clean up handling of userns
Sorry for the resend, but I found a bug that means this will fail to build on some distros / versions. Our handling of user namespaces is more complex than it needs to be. This simplifies the handling by identifying and entering (or creating) the correct userns earlier, so that later code doesn't need to deal with it any more. Along the way we make a number of other cleanups to handling of userns and setting our user and group. This is based on my earlier test command dispatch and performance test cleanup series. Changes since v1: * Fixed overenthusiastic pruning of #includes when moving the self-isolation code which broke compile on some distro versions David Gibson (10): Don't store UID & GID persistently in the context structure Split checking for root from dropping root privilege Consolidate determination of UID/GID to run as Safer handling if we can't open /proc/self/uid_map Move self-isolation code into a separate file Consolidate validation of pasta namespace options Clean up and rename conf_ns_open() Correctly handle --netns-only in pasta_start_ns() Handle userns isolation and dropping root at the same time Allow --userns when pasta spawns a command Makefile | 8 +- conf.c | 236 ++++++++++++++++++++++++++-------------------------- isolation.c | 210 ++++++++++++++++++++++++++++++++++++++++++++++ isolation.h | 15 ++++ passt.1 | 5 +- passt.c | 116 +------------------------- passt.h | 9 -- pasta.c | 91 ++++++++++++-------- pasta.h | 1 + util.c | 83 ------------------ util.h | 2 - 11 files changed, 412 insertions(+), 364 deletions(-) create mode 100644 isolation.c create mode 100644 isolation.h -- 2.37.3
c->uid and c->gid are first set in conf(), and last used in check_root()
itself called from conf(). Therefore these don't need to be fields in the
long lived context structure and can instead be locals in conf().
Signed-off-by: David Gibson
check_root() both checks to see if we are root (in the init namespace),
and if we are drops to an unprivileged user. To make future cleanups
simpler, split the checking for root (now in check_root()) from the actual
dropping of privilege (now in drop_root()).
Note that this does slightly alter semantics. Previously we would only
setuid() if we were originally root (in the init namespace). Now we will
always setuid() and setgid(), though it won't actually change anything if
we weren't privileged to begin with. This also means that we will now
always attempt to switch to the user specified with --runas, even if we
aren't (init namespace) root to begin with. Obviously this will fail with
an error if we weren't privileged to start with. --help and the man page
are updated accordingly.
Signed-off-by: David Gibson
Just some ridiculous nitpicking on this one:
On Thu, 8 Sep 2022 13:58:59 +1000
David Gibson
[...]
+++ b/passt.1 @@ -104,9 +104,10 @@ terminal, and to both system logger and standard error otherwise.
.TP .BR \-\-runas " " \fIUID\fR|\fIUID:GID\fR|\fILOGIN\fR|\fILOGIN:GROUP\fR -If started as root, change to given UID and corresponding group if UID is given, +Attempt to change to given UID and corresponding group if UID is given, or to given UID and given GID if both are given. Alternatively, login name, or -login name and group name can be passed. +login name and group name can be passed. This requires privilege (either
I'd change this to "privileges", right? Also, adding two spaces following a period, as you do, seems to have some merits: https://link.springer.com/article/10.3758/s13414-018-1527-6 Johnson, R.L., Bui, B. & Schmitt, L.L. Are two spaces better than one? The effect of spacing following periods and commas during reading. Atten Percept Psychophys 80, 1504–1511 (2018) ...but in man pages, nroff might turn that into three or more spaces, inconsistently, in a justified paragraph. I'd stick to one. Or change all of them (I almost never use two, so here it's all single spaces).
+initial effective UID 0 or CAP_SETUID capability) to work. Default is to change to user \fInobody\fR if started as root.
.TP diff --git a/util.c b/util.c index b2ccb3d..17595c1 100644 --- a/util.c +++ b/util.c @@ -492,7 +492,13 @@ void check_root(uid_t *uid, gid_t *gid) char buf[BUFSIZ]; int fd;
- if (getuid() && geteuid()) + if (!*uid) + *uid = geteuid(); + + if (!*gid) + *gid = getegid(); + + if (*uid) return;
if ((fd = open("/proc/self/uid_map", O_RDONLY | O_CLOEXEC)) < 0) @@ -524,11 +530,26 @@ void check_root(uid_t *uid, gid_t *gid) *uid = *gid = 65534; #endif } +} + +/** + * drop_root() - Switch to given UID and GID
I would add the usual: * @uid: User ID to switch to * @gid: Group ID to switch to even though it's totally obvious here, in case somebody should ever need to parse this stuff to produce documentation. -- Stefano
On Fri, Sep 09, 2022 at 04:33:27PM +0200, Stefano Brivio wrote:
Just some ridiculous nitpicking on this one:
On Thu, 8 Sep 2022 13:58:59 +1000 David Gibson
wrote: [...]
+++ b/passt.1 @@ -104,9 +104,10 @@ terminal, and to both system logger and standard error otherwise.
.TP .BR \-\-runas " " \fIUID\fR|\fIUID:GID\fR|\fILOGIN\fR|\fILOGIN:GROUP\fR -If started as root, change to given UID and corresponding group if UID is given, +Attempt to change to given UID and corresponding group if UID is given, or to given UID and given GID if both are given. Alternatively, login name, or -login name and group name can be passed. +login name and group name can be passed. This requires privilege (either
I'd change this to "privileges", right?
Hmm.. I think either would work, but I'll change it.
Also, adding two spaces following a period, as you do, seems to have some merits:
https://link.springer.com/article/10.3758/s13414-018-1527-6
Johnson, R.L., Bui, B. & Schmitt, L.L. Are two spaces better than one? The effect of spacing following periods and commas during reading. Atten Percept Psychophys 80, 1504–1511 (2018)
...but in man pages, nroff might turn that into three or more spaces, inconsistently, in a justified paragraph.
I'd stick to one. Or change all of them (I almost never use two, so here it's all single spaces).
Fair enough. I believe the question of spaces after a full stop (British/Australian English for "period") is a bit of a contentious issue. At least in the English speaking world - I gather it's rarely used outside that. It's mostly irrelevant for modern typesetting, because the typesetter will adjust anyways, I think I developed the habit from writing text documents, at least some in the age of monospaced printing. I've removed it, anyway.
+initial effective UID 0 or CAP_SETUID capability) to work. Default is to change to user \fInobody\fR if started as root.
.TP diff --git a/util.c b/util.c index b2ccb3d..17595c1 100644 --- a/util.c +++ b/util.c @@ -492,7 +492,13 @@ void check_root(uid_t *uid, gid_t *gid) char buf[BUFSIZ]; int fd;
- if (getuid() && geteuid()) + if (!*uid) + *uid = geteuid(); + + if (!*gid) + *gid = getegid(); + + if (*uid) return;
if ((fd = open("/proc/self/uid_map", O_RDONLY | O_CLOEXEC)) < 0) @@ -524,11 +530,26 @@ void check_root(uid_t *uid, gid_t *gid) *uid = *gid = 65534; #endif } +} + +/** + * drop_root() - Switch to given UID and GID
I would add the usual:
* @uid: User ID to switch to * @gid: Group ID to switch to
even though it's totally obvious here, in case somebody should ever need to parse this stuff to produce documentation.
Good point, added. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
Currently the logic to work out what UID and GID we will run as is spread
across conf(). If --runas is specified it's handled in conf_runas(),
otherwise it's handled by check_root(), which depends on initialization of
the uid and gid variables by either conf() itself or conf_runas().
Make this clearer by putting all the UID and GID logic into a single
conf_ugid() function.
Signed-off-by: David Gibson
Also mere nitpicking on this one:
On Thu, 8 Sep 2022 13:59:00 +1000
David Gibson
Currently the logic to work out what UID and GID we will run as is spread across conf(). If --runas is specified it's handled in conf_runas(), otherwise it's handled by check_root(), which depends on initialization of the uid and gid variables by either conf() itself or conf_runas().
Make this clearer by putting all the UID and GID logic into a single conf_ugid() function.
Signed-off-by: David Gibson
--- conf.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++++++------ util.c | 50 ------------------------------------ util.h | 1 - 3 files changed, 73 insertions(+), 59 deletions(-) diff --git a/conf.c b/conf.c index 545f61d..5c293b5 100644 --- a/conf.c +++ b/conf.c @@ -1021,6 +1021,70 @@ static int conf_runas(const char *opt, unsigned int *uid, unsigned int *gid) #endif /* !GLIBC_NO_STATIC_NSS */ }
+/** + * conf_ugid() - Determine UID and GID to run as + * @runas: --runas option, may be NULL + * @uid: User ID, set on success + * @gid: Group ID, set on success + * + * Return: 0 on success, negative error code on failure + */ +static int conf_ugid(const char *runas, uid_t *uid, gid_t *gid) +{ + const char root_uid_map[] = " 0 0 4294967295"; + struct passwd *pw; + char buf[BUFSIZ]; + int ret; + int fd; + + /* If user has specified --runas, that takes precedence */ + if (runas) { + ret = conf_runas(runas, uid, gid); + if (ret) + err("Invalid --runas option: %s", runas); + return ret; + } + + /* Otherwise default to current user and group.. */ + *uid = geteuid(); + *gid = getegid(); + + /* ..as long as it's not root.. */ + if (*uid) + return 0; + + /* ..or at least not root in the init namespace.. */ + if ((fd = open("/proc/self/uid_map", O_RDONLY | O_CLOEXEC)) < 0) + return 0; + + if (read(fd, buf, BUFSIZ) != sizeof(root_uid_map) || + strncmp(buf, root_uid_map, sizeof(root_uid_map) - 1)) { + close(fd); + return 0; + } + + close(fd); + + /* ..otherwise use nobody:nobody */
I'd change all those comment to use ellipses (...) instead of "..". I think your comments here help a lot, by the way (and I couldn't find a better way to check for UID 0 in non-init other than that hack). -- Stefano
On Fri, Sep 09, 2022 at 04:33:47PM +0200, Stefano Brivio wrote:
Also mere nitpicking on this one:
On Thu, 8 Sep 2022 13:59:00 +1000 David Gibson
wrote: Currently the logic to work out what UID and GID we will run as is spread across conf(). If --runas is specified it's handled in conf_runas(), otherwise it's handled by check_root(), which depends on initialization of the uid and gid variables by either conf() itself or conf_runas().
Make this clearer by putting all the UID and GID logic into a single conf_ugid() function.
Signed-off-by: David Gibson
--- conf.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++++++------ util.c | 50 ------------------------------------ util.h | 1 - 3 files changed, 73 insertions(+), 59 deletions(-) diff --git a/conf.c b/conf.c index 545f61d..5c293b5 100644 --- a/conf.c +++ b/conf.c @@ -1021,6 +1021,70 @@ static int conf_runas(const char *opt, unsigned int *uid, unsigned int *gid) #endif /* !GLIBC_NO_STATIC_NSS */ }
+/** + * conf_ugid() - Determine UID and GID to run as + * @runas: --runas option, may be NULL + * @uid: User ID, set on success + * @gid: Group ID, set on success + * + * Return: 0 on success, negative error code on failure + */ +static int conf_ugid(const char *runas, uid_t *uid, gid_t *gid) +{ + const char root_uid_map[] = " 0 0 4294967295"; + struct passwd *pw; + char buf[BUFSIZ]; + int ret; + int fd; + + /* If user has specified --runas, that takes precedence */ + if (runas) { + ret = conf_runas(runas, uid, gid); + if (ret) + err("Invalid --runas option: %s", runas); + return ret; + } + + /* Otherwise default to current user and group.. */ + *uid = geteuid(); + *gid = getegid(); + + /* ..as long as it's not root.. */ + if (*uid) + return 0; + + /* ..or at least not root in the init namespace.. */ + if ((fd = open("/proc/self/uid_map", O_RDONLY | O_CLOEXEC)) < 0) + return 0; + + if (read(fd, buf, BUFSIZ) != sizeof(root_uid_map) || + strncmp(buf, root_uid_map, sizeof(root_uid_map) - 1)) { + close(fd); + return 0; + } + + close(fd); + + /* ..otherwise use nobody:nobody */
I'd change all those comment to use ellipses (...) instead of "..".
Ok, nit picked.
I think your comments here help a lot, by the way (and I couldn't find a better way to check for UID 0 in non-init other than that hack).
Right. The extra complexity - both of code and of mental model - in going from "not UID 0" to "not UID 0 in the init namespace" is what makes me really wonder if this check is worth having. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
On Sat, 10 Sep 2022 17:15:41 +1000
David Gibson
On Fri, Sep 09, 2022 at 04:33:47PM +0200, Stefano Brivio wrote:
Also mere nitpicking on this one:
On Thu, 8 Sep 2022 13:59:00 +1000 David Gibson
wrote: Currently the logic to work out what UID and GID we will run as is spread across conf(). If --runas is specified it's handled in conf_runas(), otherwise it's handled by check_root(), which depends on initialization of the uid and gid variables by either conf() itself or conf_runas().
Make this clearer by putting all the UID and GID logic into a single conf_ugid() function.
Signed-off-by: David Gibson
--- conf.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++++++------ util.c | 50 ------------------------------------ util.h | 1 - 3 files changed, 73 insertions(+), 59 deletions(-) diff --git a/conf.c b/conf.c index 545f61d..5c293b5 100644 --- a/conf.c +++ b/conf.c @@ -1021,6 +1021,70 @@ static int conf_runas(const char *opt, unsigned int *uid, unsigned int *gid) #endif /* !GLIBC_NO_STATIC_NSS */ }
+/** + * conf_ugid() - Determine UID and GID to run as + * @runas: --runas option, may be NULL + * @uid: User ID, set on success + * @gid: Group ID, set on success + * + * Return: 0 on success, negative error code on failure + */ +static int conf_ugid(const char *runas, uid_t *uid, gid_t *gid) +{ + const char root_uid_map[] = " 0 0 4294967295"; + struct passwd *pw; + char buf[BUFSIZ]; + int ret; + int fd; + + /* If user has specified --runas, that takes precedence */ + if (runas) { + ret = conf_runas(runas, uid, gid); + if (ret) + err("Invalid --runas option: %s", runas); + return ret; + } + + /* Otherwise default to current user and group.. */ + *uid = geteuid(); + *gid = getegid(); + + /* ..as long as it's not root.. */ + if (*uid) + return 0; + + /* ..or at least not root in the init namespace.. */ + if ((fd = open("/proc/self/uid_map", O_RDONLY | O_CLOEXEC)) < 0) + return 0; + + if (read(fd, buf, BUFSIZ) != sizeof(root_uid_map) || + strncmp(buf, root_uid_map, sizeof(root_uid_map) - 1)) { + close(fd); + return 0; + } + + close(fd); + + /* ..otherwise use nobody:nobody */
I'd change all those comment to use ellipses (...) instead of "..".
Ok, nit picked.
I think your comments here help a lot, by the way (and I couldn't find a better way to check for UID 0 in non-init other than that hack).
Right. The extra complexity - both of code and of mental model - in going from "not UID 0" to "not UID 0 in the init namespace" is what makes me really wonder if this check is worth having.
I think it's desirable for two cases (rather important in my opinion): - running passt with a further isolation implemented by a user namespace (e.g. with pasta). There it's not really practical to use a non-zero UID, and allowing to do this easily is a relevant security feature - ...if I recall correctly (but I can't check right now) Podman does the same -- Stefano
On Sat, Sep 10, 2022 at 10:43:31PM +0200, Stefano Brivio wrote:
On Sat, 10 Sep 2022 17:15:41 +1000 David Gibson
wrote: On Fri, Sep 09, 2022 at 04:33:47PM +0200, Stefano Brivio wrote:
Also mere nitpicking on this one:
On Thu, 8 Sep 2022 13:59:00 +1000 David Gibson
wrote: Currently the logic to work out what UID and GID we will run as is spread across conf(). If --runas is specified it's handled in conf_runas(), otherwise it's handled by check_root(), which depends on initialization of the uid and gid variables by either conf() itself or conf_runas().
Make this clearer by putting all the UID and GID logic into a single conf_ugid() function.
Signed-off-by: David Gibson
--- conf.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++++++------ util.c | 50 ------------------------------------ util.h | 1 - 3 files changed, 73 insertions(+), 59 deletions(-) diff --git a/conf.c b/conf.c index 545f61d..5c293b5 100644 --- a/conf.c +++ b/conf.c @@ -1021,6 +1021,70 @@ static int conf_runas(const char *opt, unsigned int *uid, unsigned int *gid) #endif /* !GLIBC_NO_STATIC_NSS */ }
+/** + * conf_ugid() - Determine UID and GID to run as + * @runas: --runas option, may be NULL + * @uid: User ID, set on success + * @gid: Group ID, set on success + * + * Return: 0 on success, negative error code on failure + */ +static int conf_ugid(const char *runas, uid_t *uid, gid_t *gid) +{ + const char root_uid_map[] = " 0 0 4294967295"; + struct passwd *pw; + char buf[BUFSIZ]; + int ret; + int fd; + + /* If user has specified --runas, that takes precedence */ + if (runas) { + ret = conf_runas(runas, uid, gid); + if (ret) + err("Invalid --runas option: %s", runas); + return ret; + } + + /* Otherwise default to current user and group.. */ + *uid = geteuid(); + *gid = getegid(); + + /* ..as long as it's not root.. */ + if (*uid) + return 0; + + /* ..or at least not root in the init namespace.. */ + if ((fd = open("/proc/self/uid_map", O_RDONLY | O_CLOEXEC)) < 0) + return 0; + + if (read(fd, buf, BUFSIZ) != sizeof(root_uid_map) || + strncmp(buf, root_uid_map, sizeof(root_uid_map) - 1)) { + close(fd); + return 0; + } + + close(fd); + + /* ..otherwise use nobody:nobody */
I'd change all those comment to use ellipses (...) instead of "..".
Ok, nit picked.
I think your comments here help a lot, by the way (and I couldn't find a better way to check for UID 0 in non-init other than that hack).
Right. The extra complexity - both of code and of mental model - in going from "not UID 0" to "not UID 0 in the init namespace" is what makes me really wonder if this check is worth having.
I think it's desirable for two cases (rather important in my opinion):
- running passt with a further isolation implemented by a user namespace (e.g. with pasta). There it's not really practical to use a non-zero UID, and allowing to do this easily is a relevant security feature
- ...if I recall correctly (but I can't check right now) Podman does the same
Sorry, I realize I wasn't clear. We absolutely need the ability to run as "root" (UID 0) within a user namespace. What I'm questioning is given that whether it's worth preventing running when UID 0 outside a user namespace (as far as we can tell). There's arguably some edge cases where it might be useful, and it's debatable whether it's passt's job to prevent the user from shooting themselves in the foot in this way. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
On Mon, 12 Sep 2022 19:53:38 +1000
David Gibson
On Sat, Sep 10, 2022 at 10:43:31PM +0200, Stefano Brivio wrote:
On Sat, 10 Sep 2022 17:15:41 +1000 David Gibson
wrote: On Fri, Sep 09, 2022 at 04:33:47PM +0200, Stefano Brivio wrote:
Also mere nitpicking on this one:
On Thu, 8 Sep 2022 13:59:00 +1000 David Gibson
wrote: Currently the logic to work out what UID and GID we will run as is spread across conf(). If --runas is specified it's handled in conf_runas(), otherwise it's handled by check_root(), which depends on initialization of the uid and gid variables by either conf() itself or conf_runas().
Make this clearer by putting all the UID and GID logic into a single conf_ugid() function.
Signed-off-by: David Gibson
--- conf.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++++++------ util.c | 50 ------------------------------------ util.h | 1 - 3 files changed, 73 insertions(+), 59 deletions(-) diff --git a/conf.c b/conf.c index 545f61d..5c293b5 100644 --- a/conf.c +++ b/conf.c @@ -1021,6 +1021,70 @@ static int conf_runas(const char *opt, unsigned int *uid, unsigned int *gid) #endif /* !GLIBC_NO_STATIC_NSS */ }
+/** + * conf_ugid() - Determine UID and GID to run as + * @runas: --runas option, may be NULL + * @uid: User ID, set on success + * @gid: Group ID, set on success + * + * Return: 0 on success, negative error code on failure + */ +static int conf_ugid(const char *runas, uid_t *uid, gid_t *gid) +{ + const char root_uid_map[] = " 0 0 4294967295"; + struct passwd *pw; + char buf[BUFSIZ]; + int ret; + int fd; + + /* If user has specified --runas, that takes precedence */ + if (runas) { + ret = conf_runas(runas, uid, gid); + if (ret) + err("Invalid --runas option: %s", runas); + return ret; + } + + /* Otherwise default to current user and group.. */ + *uid = geteuid(); + *gid = getegid(); + + /* ..as long as it's not root.. */ + if (*uid) + return 0; + + /* ..or at least not root in the init namespace.. */ + if ((fd = open("/proc/self/uid_map", O_RDONLY | O_CLOEXEC)) < 0) + return 0; + + if (read(fd, buf, BUFSIZ) != sizeof(root_uid_map) || + strncmp(buf, root_uid_map, sizeof(root_uid_map) - 1)) { + close(fd); + return 0; + } + + close(fd); + + /* ..otherwise use nobody:nobody */
I'd change all those comment to use ellipses (...) instead of "..".
Ok, nit picked.
I think your comments here help a lot, by the way (and I couldn't find a better way to check for UID 0 in non-init other than that hack).
Right. The extra complexity - both of code and of mental model - in going from "not UID 0" to "not UID 0 in the init namespace" is what makes me really wonder if this check is worth having.
I think it's desirable for two cases (rather important in my opinion):
- running passt with a further isolation implemented by a user namespace (e.g. with pasta). There it's not really practical to use a non-zero UID, and allowing to do this easily is a relevant security feature
- ...if I recall correctly (but I can't check right now) Podman does the same
Sorry, I realize I wasn't clear. We absolutely need the ability to run as "root" (UID 0) within a user namespace. What I'm questioning is given that whether it's worth preventing running when UID 0 outside a user namespace (as far as we can tell). There's arguably some edge cases where it might be useful, and it's debatable whether it's passt's job to prevent the user from shooting themselves in the foot in this way.
Ah, I see now. Well, I also think it's debatable, and I'd even tend to say it's not actually passt's job, but I still think there are three reasons to keep doing this: - user mistakes happen, and it's also arguably our job to make usage less error-prone - if users run this as root, we won't actually run as root, so we obtain an essentially equivalent level of security while letting lazy/distracted users do whatever... compared to the alternative, it sounds appealing - given that it's debatable (for instance, many other tools and daemons do the same), I'd keep erring on the side of caution, as this might significantly decide the perceived, or factual, severity of any vulnerability that might be found I also guess that forcing users to rebuild from source if they want to do is reasonable for those edge cases. -- Stefano
On Tue, Sep 13, 2022 at 05:49:52AM +0200, Stefano Brivio wrote:
On Mon, 12 Sep 2022 19:53:38 +1000 David Gibson
wrote: On Sat, Sep 10, 2022 at 10:43:31PM +0200, Stefano Brivio wrote:
On Sat, 10 Sep 2022 17:15:41 +1000 David Gibson
wrote: On Fri, Sep 09, 2022 at 04:33:47PM +0200, Stefano Brivio wrote:
Also mere nitpicking on this one:
On Thu, 8 Sep 2022 13:59:00 +1000 David Gibson
wrote: Currently the logic to work out what UID and GID we will run as is spread across conf(). If --runas is specified it's handled in conf_runas(), otherwise it's handled by check_root(), which depends on initialization of the uid and gid variables by either conf() itself or conf_runas().
Make this clearer by putting all the UID and GID logic into a single conf_ugid() function.
Signed-off-by: David Gibson
--- conf.c | 81 ++++++++++++++++++++++++++++++++++++++++++++++++++++------ util.c | 50 ------------------------------------ util.h | 1 - 3 files changed, 73 insertions(+), 59 deletions(-) diff --git a/conf.c b/conf.c index 545f61d..5c293b5 100644 --- a/conf.c +++ b/conf.c @@ -1021,6 +1021,70 @@ static int conf_runas(const char *opt, unsigned int *uid, unsigned int *gid) #endif /* !GLIBC_NO_STATIC_NSS */ }
+/** + * conf_ugid() - Determine UID and GID to run as + * @runas: --runas option, may be NULL + * @uid: User ID, set on success + * @gid: Group ID, set on success + * + * Return: 0 on success, negative error code on failure + */ +static int conf_ugid(const char *runas, uid_t *uid, gid_t *gid) +{ + const char root_uid_map[] = " 0 0 4294967295"; + struct passwd *pw; + char buf[BUFSIZ]; + int ret; + int fd; + + /* If user has specified --runas, that takes precedence */ + if (runas) { + ret = conf_runas(runas, uid, gid); + if (ret) + err("Invalid --runas option: %s", runas); + return ret; + } + + /* Otherwise default to current user and group.. */ + *uid = geteuid(); + *gid = getegid(); + + /* ..as long as it's not root.. */ + if (*uid) + return 0; + + /* ..or at least not root in the init namespace.. */ + if ((fd = open("/proc/self/uid_map", O_RDONLY | O_CLOEXEC)) < 0) + return 0; + + if (read(fd, buf, BUFSIZ) != sizeof(root_uid_map) || + strncmp(buf, root_uid_map, sizeof(root_uid_map) - 1)) { + close(fd); + return 0; + } + + close(fd); + + /* ..otherwise use nobody:nobody */
I'd change all those comment to use ellipses (...) instead of "..".
Ok, nit picked.
I think your comments here help a lot, by the way (and I couldn't find a better way to check for UID 0 in non-init other than that hack).
Right. The extra complexity - both of code and of mental model - in going from "not UID 0" to "not UID 0 in the init namespace" is what makes me really wonder if this check is worth having.
I think it's desirable for two cases (rather important in my opinion):
- running passt with a further isolation implemented by a user namespace (e.g. with pasta). There it's not really practical to use a non-zero UID, and allowing to do this easily is a relevant security feature
- ...if I recall correctly (but I can't check right now) Podman does the same
Sorry, I realize I wasn't clear. We absolutely need the ability to run as "root" (UID 0) within a user namespace. What I'm questioning is given that whether it's worth preventing running when UID 0 outside a user namespace (as far as we can tell). There's arguably some edge cases where it might be useful, and it's debatable whether it's passt's job to prevent the user from shooting themselves in the foot in this way.
Ah, I see now.
Well, I also think it's debatable, and I'd even tend to say it's not actually passt's job, but I still think there are three reasons to keep doing this:
- user mistakes happen, and it's also arguably our job to make usage less error-prone
- if users run this as root, we won't actually run as root, so we obtain an essentially equivalent level of security while letting lazy/distracted users do whatever... compared to the alternative, it sounds appealing
- given that it's debatable (for instance, many other tools and daemons do the same), I'd keep erring on the side of caution, as this might significantly decide the perceived, or factual, severity of any vulnerability that might be found
I also guess that forcing users to rebuild from source if they want to do is reasonable for those edge cases.
Yeah, I guess that's fair enough. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
passt is allowed to run as "root" (UID 0) in a user namespace, but notas
real root in the init namespace. We read /proc/self/uid_map to determine
if we're in the init namespace or not.
If we're unable to open /proc/self/uid_map we assume we're ok and continue
running as UID 0. This seems unwise: AFAIK the only instance in which
uid_map won't be available is if we're running on a kernel which doesn't
support user namespaces, in which case we won't be able to sandbox
ourselves as we want and fail anyway. If there are other circumstances
where it can't be opened it seems marginally more likely that we *are*
in the init namespace.
Therefore, fail with an error in this case, instead of carrying on.
Signed-off-by: David Gibson
On Thu, 8 Sep 2022 13:59:01 +1000
David Gibson
passt is allowed to run as "root" (UID 0) in a user namespace, but notas real root in the init namespace. We read /proc/self/uid_map to determine if we're in the init namespace or not.
If we're unable to open /proc/self/uid_map we assume we're ok and continue running as UID 0. This seems unwise: AFAIK the only instance in which uid_map won't be available is if we're running on a kernel which doesn't support user namespaces, in which case we won't be able to sandbox ourselves as we want and fail anyway.
Well, if user namespaces are not supported and the UID is 0, then we're actually running as root, so we should quit anyway.
If there are other circumstances where it can't be opened it seems marginally more likely that we *are* in the init namespace.
That could also happen if procfs is not mounted, but I'm not sure what would work then.
Therefore, fail with an error in this case, instead of carrying on.
Yes, absolutely. -- Stefano
On Fri, Sep 09, 2022 at 04:33:52PM +0200, Stefano Brivio wrote:
On Thu, 8 Sep 2022 13:59:01 +1000 David Gibson
wrote: passt is allowed to run as "root" (UID 0) in a user namespace, but notas real root in the init namespace. We read /proc/self/uid_map to determine if we're in the init namespace or not.
If we're unable to open /proc/self/uid_map we assume we're ok and continue running as UID 0. This seems unwise: AFAIK the only instance in which uid_map won't be available is if we're running on a kernel which doesn't support user namespaces, in which case we won't be able to sandbox ourselves as we want and fail anyway.
Well, if user namespaces are not supported and the UID is 0, then we're actually running as root, so we should quit anyway.
Right, that's kind of the whole point of this patch, but it's a bit obscured in the wording here because I realized we'd actually fail later anyway.
If there are other circumstances where it can't be opened it seems marginally more likely that we *are* in the init namespace.
That could also happen if procfs is not mounted, but I'm not sure what would work then.
True. I'll reword the commit message to make both points clearer.
Therefore, fail with an error in this case, instead of carrying on.
Yes, absolutely.
-- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
passt/pasta contains a number of routines designed to isolate passt from
the rest of the system for security. These are spread through util.c and
passt.c. Move them together into a new isolation.c file.
Signed-off-by: David Gibson
On Thu, 8 Sep 2022 13:59:02 +1000
David Gibson
[...]
+++ b/isolation.c
[...]
+/** + * sandbox() - Unshare IPC, mount, PID, UTS, and user namespaces, "unmount" root + * + * Return: negative error code on failure, zero on success + */ +int sandbox(struct ctx *c)
Same here, I would "document" "c". -- Stefano
On Fri, Sep 09, 2022 at 04:33:58PM +0200, Stefano Brivio wrote:
On Thu, 8 Sep 2022 13:59:02 +1000 David Gibson
wrote: [...]
+++ b/isolation.c
[...]
+/** + * sandbox() - Unshare IPC, mount, PID, UTS, and user namespaces, "unmount" root + * + * Return: negative error code on failure, zero on success + */ +int sandbox(struct ctx *c)
Same here, I would "document" "c".
Not in scope for this patch, since it's a pure code motion. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
On Sat, 10 Sep 2022 17:23:56 +1000
David Gibson
On Fri, Sep 09, 2022 at 04:33:58PM +0200, Stefano Brivio wrote:
On Thu, 8 Sep 2022 13:59:02 +1000 David Gibson
wrote: [...]
+++ b/isolation.c
[...]
+/** + * sandbox() - Unshare IPC, mount, PID, UTS, and user namespaces, "unmount" root + * + * Return: negative error code on failure, zero on success + */ +int sandbox(struct ctx *c)
Same here, I would "document" "c".
Not in scope for this patch, since it's a pure code motion.
Whoops, my bad, I didn't notice. -- Stefano
There are a number of different ways to specify namespaces for pasta to
use. Some combinations are valid and some are not. Currently validation
for these is spread across several places: conf_ns_pid() validates PID
options specifically. Near its callsite in conf() several other checks
are made. Some additional checks are made in conf_ns_open() and finally
theres a check just before the call to pasta_start_ns().
This is quite hard to follow. Make it easier by putting all the validation
logic together in a new conf_pasta_ns() function, which subsumes
conf_ns_pid(). This reveals that some of the checks were redundant with
each other, so remove those.
For good measure, rename conf_netns() to conf_netns_opt() to make it
clearer its handling just the --netns option specifically, not overall
configuration of the netns.
Signed-off-by: David Gibson
conf_ns_open() opens file descriptors for the namespaces pasta needs, but
it doesnt really have anything to do with configuration any more. For
better clarity, move it to pasta.c and rename it pasta_open_ns(). This
makes the symmetry between it and pasta_start_ns() more clear, since these
represent the two basic ways that pasta can operate, either attaching to
an existing namespace/process or spawning a new one.
Since its no longer validating options, the errors it could return
shouldn't cause a usage message. Just exit directly with an error instead.
Signed-off-by: David Gibson
--netns-only is supposed to make pasta use only a network namespace, not
a user namespace. However, pasta_start_ns() has this backwards, and if
--netns-only is specified it creates a user namespace but *not* a network
namespace. Correct this.
Signed-off-by: David Gibson
On Thu, 8 Sep 2022 13:59:05 +1000
David Gibson
--netns-only is supposed to make pasta use only a network namespace, not a user namespace. However, pasta_start_ns() has this backwards, and if --netns-only is specified it creates a user namespace but *not* a network namespace. Correct this.
Signed-off-by: David Gibson
--- pasta.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pasta.c b/pasta.c index 0fd45e4..7eac8e9 100644 --- a/pasta.c +++ b/pasta.c @@ -244,8 +244,8 @@ void pasta_start_ns(struct ctx *c, int argc, char *argv[])
pasta_child_pid = clone(pasta_setup_ns, ns_fn_stack + sizeof(ns_fn_stack) / 2, - (c->netns_only ? 0 : CLONE_NEWNET) | - CLONE_NEWIPC | CLONE_NEWPID | CLONE_NEWUSER | + (c->netns_only ? 0 : CLONE_NEWUSER) | + CLONE_NEWIPC | CLONE_NEWPID | CLONE_NEWNET |
Oh, funny, so it never worked in this case. I thought anyway your plan was to drop --netns-only altogether, and if a --netns option is specified without --userns, then it's implied. Is that still on the table (outside the scope of this series I presume)? -- Stefano
On Fri, Sep 09, 2022 at 04:34:20PM +0200, Stefano Brivio wrote:
On Thu, 8 Sep 2022 13:59:05 +1000 David Gibson
wrote: --netns-only is supposed to make pasta use only a network namespace, not a user namespace. However, pasta_start_ns() has this backwards, and if --netns-only is specified it creates a user namespace but *not* a network namespace. Correct this.
Signed-off-by: David Gibson
--- pasta.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pasta.c b/pasta.c index 0fd45e4..7eac8e9 100644 --- a/pasta.c +++ b/pasta.c @@ -244,8 +244,8 @@ void pasta_start_ns(struct ctx *c, int argc, char *argv[])
pasta_child_pid = clone(pasta_setup_ns, ns_fn_stack + sizeof(ns_fn_stack) / 2, - (c->netns_only ? 0 : CLONE_NEWNET) | - CLONE_NEWIPC | CLONE_NEWPID | CLONE_NEWUSER | + (c->netns_only ? 0 : CLONE_NEWUSER) | + CLONE_NEWIPC | CLONE_NEWPID | CLONE_NEWNET |
Oh, funny, so it never worked in this case.
I thought anyway your plan was to drop --netns-only altogether, and if a --netns option is specified without --userns, then it's implied. Is that still on the table (outside the scope of this series I presume)?
Well.. having reduced the lifetome of netns_only to within conf() alone, I felt a lot less urgency about removing it entirely. It might still be nicer to remove it anyway; I'll have another look. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
On Sat, Sep 10, 2022 at 05:25:36PM +1000, David Gibson wrote:
On Fri, Sep 09, 2022 at 04:34:20PM +0200, Stefano Brivio wrote:
On Thu, 8 Sep 2022 13:59:05 +1000 David Gibson
wrote: --netns-only is supposed to make pasta use only a network namespace, not a user namespace. However, pasta_start_ns() has this backwards, and if --netns-only is specified it creates a user namespace but *not* a network namespace. Correct this.
Signed-off-by: David Gibson
--- pasta.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pasta.c b/pasta.c index 0fd45e4..7eac8e9 100644 --- a/pasta.c +++ b/pasta.c @@ -244,8 +244,8 @@ void pasta_start_ns(struct ctx *c, int argc, char *argv[])
pasta_child_pid = clone(pasta_setup_ns, ns_fn_stack + sizeof(ns_fn_stack) / 2, - (c->netns_only ? 0 : CLONE_NEWNET) | - CLONE_NEWIPC | CLONE_NEWPID | CLONE_NEWUSER | + (c->netns_only ? 0 : CLONE_NEWUSER) | + CLONE_NEWIPC | CLONE_NEWPID | CLONE_NEWNET |
Oh, funny, so it never worked in this case.
I thought anyway your plan was to drop --netns-only altogether, and if a --netns option is specified without --userns, then it's implied. Is that still on the table (outside the scope of this series I presume)?
Well.. having reduced the lifetome of netns_only to within conf() alone, I felt a lot less urgency about removing it entirely. It might still be nicer to remove it anyway; I'll have another look.
Actually, I realized there is a reason to leave it in: just using --netns doesn't work with spawning a command, and spawning a command with netns but no userns might be useful. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
On Sun, 11 Sep 2022 18:26:31 +1000
David Gibson
On Sat, Sep 10, 2022 at 05:25:36PM +1000, David Gibson wrote:
On Fri, Sep 09, 2022 at 04:34:20PM +0200, Stefano Brivio wrote:
On Thu, 8 Sep 2022 13:59:05 +1000 David Gibson
wrote: --netns-only is supposed to make pasta use only a network namespace, not a user namespace. However, pasta_start_ns() has this backwards, and if --netns-only is specified it creates a user namespace but *not* a network namespace. Correct this.
Signed-off-by: David Gibson
--- pasta.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pasta.c b/pasta.c index 0fd45e4..7eac8e9 100644 --- a/pasta.c +++ b/pasta.c @@ -244,8 +244,8 @@ void pasta_start_ns(struct ctx *c, int argc, char *argv[])
pasta_child_pid = clone(pasta_setup_ns, ns_fn_stack + sizeof(ns_fn_stack) / 2, - (c->netns_only ? 0 : CLONE_NEWNET) | - CLONE_NEWIPC | CLONE_NEWPID | CLONE_NEWUSER | + (c->netns_only ? 0 : CLONE_NEWUSER) | + CLONE_NEWIPC | CLONE_NEWPID | CLONE_NEWNET |
Oh, funny, so it never worked in this case.
I thought anyway your plan was to drop --netns-only altogether, and if a --netns option is specified without --userns, then it's implied. Is that still on the table (outside the scope of this series I presume)?
Well.. having reduced the lifetome of netns_only to within conf() alone, I felt a lot less urgency about removing it entirely. It might still be nicer to remove it anyway; I'll have another look.
Actually, I realized there is a reason to leave it in: just using --netns doesn't work with spawning a command, and spawning a command with netns but no userns might be useful.
Right, thanks for noticing, that combination didn't occur to me at all. -- Stefano
passt/pasta can interact with user namespaces in a number of ways:
1) With --netns-only we'll remain in our original user namespace
2) With --userns or a PID option to pasta we'll join either the given
user namespace or that of the PID
3) When pasta spawns a shell or command we'll start a new user namespace
for the command and then join it
4) With passt we'll create a new user namespace when we sandbox()
ourself
However (3) and (4) turn out to have essentially the same effect. In both
cases we create one new user namespace. The spawned command starts there,
and passt/pasta itself will live there from sandbox() onwards.
Because of this, we can simplify user namespace handling by moving the
userns handling earlier, to the same point we drop root in the original
namespace. Extend the drop_user() function to isolate_user() which does
both.
After switching UID and GID in the original userns, isolate_user() will
either join or create the userns we require. When we spawn a command with
pasta_start_ns()/pasta_setup_ns() we no longer need to create a userns,
because we're already made one. sandbox() likewise no longer needs to
create (or join) an userns because we're already in the one we need.
We no longer need c->pasta_userns_fd, since the fd is only used locally
in isolate_user(). Likewise we can replace c->netns_only with a local
in conf(), since it's not used outside there.
Signed-off-by: David Gibson
Currently --userns is only allowed when pasta is attaching to an existing
netns or PID, and is prohibited when creating a new netns by spawning a
command or shell.
With the new handling of userns, this check isn't neccessary. I'm not sure
if there's any use case for --userns with a spawned command, but it's
strictly more flexible and requires zero extra code, so we might as well.
Signed-off-by: David Gibson
On Thu, 8 Sep 2022 13:59:07 +1000
David Gibson
Currently --userns is only allowed when pasta is attaching to an existing netns or PID, and is prohibited when creating a new netns by spawning a command or shell.
With the new handling of userns, this check isn't neccessary. I'm not sure if there's any use case for --userns with a spawned command, but it's strictly more flexible and requires zero extra code, so we might as well.
I think it's helpful because one might not be able to join a network namespace without first joining a given user namespace. So, if you want to run any network-ish command in such a network namespace, using pasta instead of nsenter for whatever reason, this possibility might be practical.
Signed-off-by: David Gibson
--- conf.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/conf.c b/conf.c index 27d520e..ec191c2 100644 --- a/conf.c +++ b/conf.c @@ -561,11 +561,6 @@ static int conf_pasta_ns(int *netns_only, char *userns, char *netns, } }
- if (*userns && !*netns) { - err("--userns requires --netns or PID"); - return -EINVAL; - }
I guess we should now drop this sentence about --userns from the man page: This option requires --netns or a PID to be specified. ...either drop it, or clarify that a command might also be given instead, I'm not sure. -- Stefano
On Fri, Sep 09, 2022 at 04:34:25PM +0200, Stefano Brivio wrote:
On Thu, 8 Sep 2022 13:59:07 +1000 David Gibson
wrote: Currently --userns is only allowed when pasta is attaching to an existing netns or PID, and is prohibited when creating a new netns by spawning a command or shell.
With the new handling of userns, this check isn't neccessary. I'm not sure if there's any use case for --userns with a spawned command, but it's strictly more flexible and requires zero extra code, so we might as well.
I think it's helpful because one might not be able to join a network namespace without first joining a given user namespace.
Well.. this is strictly for the spawning command case, so we're creating the network ns rather than joining one.
So, if you want to run any network-ish command in such a network namespace, using pasta instead of nsenter for whatever reason, this possibility might be practical.
Signed-off-by: David Gibson
--- conf.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/conf.c b/conf.c index 27d520e..ec191c2 100644 --- a/conf.c +++ b/conf.c @@ -561,11 +561,6 @@ static int conf_pasta_ns(int *netns_only, char *userns, char *netns, } }
- if (*userns && !*netns) { - err("--userns requires --netns or PID"); - return -EINVAL; - }
I guess we should now drop this sentence about --userns from the man page:
This option requires --netns or a PID to be specified.
...either drop it, or clarify that a command might also be given instead, I'm not sure.
Good point, I'll adjust. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
On Sat, 10 Sep 2022 17:29:35 +1000
David Gibson
On Fri, Sep 09, 2022 at 04:34:25PM +0200, Stefano Brivio wrote:
On Thu, 8 Sep 2022 13:59:07 +1000 David Gibson
wrote: Currently --userns is only allowed when pasta is attaching to an existing netns or PID, and is prohibited when creating a new netns by spawning a command or shell.
With the new handling of userns, this check isn't neccessary. I'm not sure if there's any use case for --userns with a spawned command, but it's strictly more flexible and requires zero extra code, so we might as well.
I think it's helpful because one might not be able to join a network namespace without first joining a given user namespace.
Well.. this is strictly for the spawning command case, so we're creating the network ns rather than joining one.
Ah, you're right. Then I'm also not sure. But yes, it's negative lines of code, so why not. -- Stefano
On Thu, 8 Sep 2022 13:58:57 +1000
David Gibson
Sorry for the resend, but I found a bug that means this will fail to build on some distros / versions.
Our handling of user namespaces is more complex than it needs to be. This simplifies the handling by identifying and entering (or creating) the correct userns earlier, so that later code doesn't need to deal with it any more.
Along the way we make a number of other cleanups to handling of userns and setting our user and group.
This is based on my earlier test command dispatch and performance test cleanup series.
Changes since v1: * Fixed overenthusiastic pruning of #includes when moving the self-isolation code which broke compile on some distro versions
I haven't tested this yet, but it looks great. I can fix up those small things I reported directly while merging, if you agree, and apply. A suggestion on how to update the man page as a result of 10/10 would help, though. -- Stefano
On Fri, Sep 09, 2022 at 04:36:21PM +0200, Stefano Brivio wrote:
On Thu, 8 Sep 2022 13:58:57 +1000 David Gibson
wrote: Sorry for the resend, but I found a bug that means this will fail to build on some distros / versions.
Our handling of user namespaces is more complex than it needs to be. This simplifies the handling by identifying and entering (or creating) the correct userns earlier, so that later code doesn't need to deal with it any more.
Along the way we make a number of other cleanups to handling of userns and setting our user and group.
This is based on my earlier test command dispatch and performance test cleanup series.
Changes since v1: * Fixed overenthusiastic pruning of #includes when moving the self-isolation code which broke compile on some distro versions
I haven't tested this yet, but it looks great.
I can fix up those small things I reported directly while merging, if you agree, and apply.
A suggestion on how to update the man page as a result of 10/10 would help, though.
I'll respin next week with that adjusted amongst other nits. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
participants (2)
-
David Gibson
-
Stefano Brivio