archive mirror
 help / color / mirror / Atom feed
From: Christian Brauner <>
To: Kees Cook <>,
	Linus Torvalds <>
Cc:, Andrea Righi <>
Subject: Regression when writing to /proc/<pid>/attr/
Date: Mon, 7 Jun 2021 16:22:45 +0200	[thread overview]
Message-ID: <20210607142245.eikvyeacqwwu6dn3@wittgenstein> (raw)

Hey Linus,
hey Kees,

This morning I got a report about regressions when running containers
using lsm profiles when spawning a new process into a container. Andrea
bisected this to: bfb819ea20ce ("proc: Check /proc/$pid/attr/ writes
against file opener")

Spawning a new process into a running container is a bit messy due to
accumulated legacy cruft and here's one way we're currently doing it.
Parent process -> immediate process -> attached process: the
intermediate process is needed to attach to the container's namespaces
and then we fork so that the "attached process" is a proper member of
the pid namespace of the container, i.e. a child of PID 1 in the new pid

The IPC mechanism is:

 * IPC mechanism: (X is receiver)
 *   initial process        transient process   attached process
 *        X           <---  send pid of
 *                          attached proc,
 *                          then exit
 *    send 0 ------------------------------------>    X
 *                                              [do initialization]
 *        X  <------------------------------------  send 1
 *   [add to cgroup, ...]
 *    send 2 ------------------------------------>    X
 *        X  <------------------------------------  send 3
 *   [open LSM label fd]
 *    send 4 ------------------------------------>    X
 *   						[set LSM label]
 *   close socket                                 close socket
 *                                                run program

With your fix Kees, the last step where the attached process writes its
own lsm profile fails with EPERM where it would succeed before. That
means v5.13 breaks all container users currently where it has worked
continuously before. :)

The LSM profile is written after we've become root in our new namespace

	if (!lxc_drop_groups())
		goto on_error;

	if (options->namespaces & CLONE_NEWUSER)
		if (!lxc_switch_uid_gid(ctx->setup_ns_uid, ctx->setup_ns_gid))
			goto on_error;

	if (attach_lsm(options) && ctx->lsm_label) {
		/* Change into our new LSM profile. */
		ret = ctx->lsm_ops->process_label_set_at(ctx->lsm_ops, fd_lsm, ctx->lsm_label, on_exec);
		if (ret < 0)
			goto on_error;


		TRACE("Set %s LSM label to \"%s\"", ctx->lsm_ops->name, ctx->lsm_label);

So the effective ids of the process writing the lsm profile are
different from the ids of the process that opened the lsm fd in this


             reply	other threads:[~2021-06-07 14:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-07 14:22 Christian Brauner [this message]
2021-06-07 23:38 ` Kees Cook
2021-06-08  0:02   ` Linus Torvalds
2021-06-08  2:15     ` Kees Cook
2021-06-08  6:44       ` Andrea Righi
2021-06-08 17:03         ` Kees Cook
2021-06-08 11:59       ` Christian Brauner
2021-06-08 16:39         ` Linus Torvalds
2021-06-08  8:51   ` Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210607142245.eikvyeacqwwu6dn3@wittgenstein \ \ \ \ \ \
    --subject='Re: Regression when writing to /proc/<pid>/attr/' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).