archive mirror
 help / color / mirror / Atom feed
From: Aleksa Sarai <>
To: Christian Brauner <>
Cc: Jann Horn <>, Andy Lutomirski <>,
	Aleksa Sarai <>,
	Al Viro <>,
	Jeff Layton <>,
	"J. Bruce Fields" <>,
	Arnd Bergmann <>,
	David Howells <>,
	Eric Biederman <>,
	Andrew Morton <>,
	Alexei Starovoitov <>,
	Kees Cook <>,
	Tycho Andersen <>,
	David Drysdale <>,
	Chanho Min <>, Oleg Nesterov <>,
	Linus Torvalds <>,
	Linux Containers <>,
	linux-fsdevel <>,
	Linux API <>,
	kernel list <>,
	linux-arch <>
Subject: Re: [PATCH v6 5/6] binfmt_*: scope path resolution of interpreters
Date: Sun, 12 May 2019 01:49:23 +1000	[thread overview]
Message-ID: <20190511154923.z5woxv4dqperuqty@mikami> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 3202 bytes --]

On 2019-05-11, Christian Brauner <> wrote:
> > In my opinion, the problems here are:
> >
> >  - Apparently some people run untrusted containers without user
> >    namespaces. It would be really nice if people could not do that.
> >    (Probably the biggest problem here.)
> I know I sound like a broken record since I've been going on about this
> forever together with a lot of other people but honestly,
> the fact that people are running untrusted workloads in privileged containers
> is the real issue here.

I completely agree. It's a shit-show, and it's caused by bad defaults in
Docker and (now) podman. To be fair, they both now support rootless
containers but the default is still privileged containers.

They do support user namespaces (though it should be noted that LXD's
support is much nicer from a security standpoint) but unless it's the
default the support is almost pointless. In the case of Docker it can
lead to some usability issues when you enable it (which I believe is the
main justification for it not being the default).

> Aleksa is a good friend of mine and we have discussed this a lot so I hope
> he doesn't hate me for saying this again: it is crazy that there are container
> runtimes out there that promise (or at least do not state the opposite)
> containers without user namespaces or containers with user namespaces
> that allow to map the host root id to anything can be safe. They cannot.

Yeah, the fact that we (runc) don't scream from the rooftops that this
setup is insecure is definitely a problem. I have mentioned this
whenever I've had a chance, but the fact that the most popular runtimes
(which use runc) don't use user namespaces compounds the issue. I'm
willing to bet that >90% of users of runc-based runtimes don't use user
namespaces at all, and this is all down to bad defaults.

There are also some other misfeatures we have in runc that we're
basically forced to support because some users use them, and we can't
really break entire projects (even though it's the projects' fault they
have an insecure setup).

> It seems to me to be heading in the wrong direction to keep up the
> illusion that with enough effort we can make this all nice and safe.
> Yes, the userspace memfd hack we came up with is as ugly as a security
> patch can be but if you make promises you can't keep you better be
> prepared to pay the price when things start to fall apart.

> So if this part of the patch is just needed to handle this do we really
> want to do all that tricky work or is there more to gain from this that
> makes it worth it.

I dropped this patch in v7, I don't think it's required for the
overarching feature. Looking back on it, it doesn't make much sense
given the context that privileged containers are unsafe in the first

I do think that being able to block introspection might be a useful
hardening feature though. During attachment it would be nice to be sure
that nothing will be able to touch the attaching process's /proc/$pid --
even itself.

Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2019-05-11 15:49 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-06 16:54 [PATCH v6 0/6] namei: resolveat(2) path resolution restriction API Aleksa Sarai
2019-05-06 16:54 ` [PATCH v6 1/6] namei: split out nd->dfd handling to dirfd_path_init Aleksa Sarai
2019-05-06 16:54 ` [PATCH v6 2/6] namei: O_BENEATH-style path resolution flags Aleksa Sarai
2019-05-06 16:54 ` [PATCH v6 3/6] namei: LOOKUP_IN_ROOT: chroot-like path resolution Aleksa Sarai
2019-05-06 16:54 ` [PATCH v6 4/6] namei: aggressively check for nd->root escape on ".." resolution Aleksa Sarai
2019-05-06 16:54 ` [PATCH v6 5/6] binfmt_*: scope path resolution of interpreters Aleksa Sarai
2019-05-06 18:37   ` Jann Horn
2019-05-06 19:17     ` Aleksa Sarai
2019-05-06 23:41       ` Andy Lutomirski
2019-05-08  0:54       ` Aleksa Sarai
2019-05-10 20:41       ` Jann Horn
2019-05-10 21:20         ` Andy Lutomirski
2019-05-10 22:55           ` Jann Horn
2019-05-10 23:36             ` Christian Brauner
2019-05-11 15:49               ` Aleksa Sarai [this message]
2019-05-11 17:00             ` Andy Lutomirski
2019-05-11 17:21               ` Linus Torvalds
2019-05-11 17:26                 ` Linus Torvalds
2019-05-11 17:31                   ` Aleksa Sarai
2019-05-11 17:43                     ` Linus Torvalds
2019-05-11 17:48                       ` Christian Brauner
2019-05-11 18:00                       ` Aleksa Sarai
2019-05-11 22:39                 ` Andy Lutomirski
     [not found]                   ` <>
2019-05-12 10:19                     ` Christian Brauner
     [not found]                     ` <>
2019-05-12 10:44                       ` Linus Torvalds
2019-05-12 13:35                         ` Aleksa Sarai
2019-05-12 13:38                           ` Aleksa Sarai
2019-05-12 14:34                           ` Andy Lutomirski
2019-05-11 17:26               ` Aleksa Sarai
2019-05-08  0:38     ` Eric W. Biederman
2019-05-10 20:10       ` Jann Horn
2019-05-06 16:54 ` [PATCH v6 6/6] namei: resolveat(2) syscall Aleksa Sarai

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=20190511154923.z5woxv4dqperuqty@mikami \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).