Comment by deathanatos | Hacker News Reader

Comment by deathanatos | Hacker News Reader

While I'm not sure I agree entirely with the "Complexity == Bugs" section, the main point, that containers are first-class citizens but a (useful) combination of independent mechanisms is spot-on. This has real repercussions: most people I've spoken do don't know these things exist. They know containers do, they have a very vague idea what containers are, but they have no fundamental understanding of the underlying concepts. (And who can blame them? Really, it was marketed that way.)

For example, pid_namespaces, and subreapers are an awesome feature¹, and are extremely handy if you have a daemon that needs to keep track of a set of child jobs that may or may not be well behaved. pid_namespaces ensure that if something bad happens to the parent, the children are terminated; they don't ignorantly continue executing after being reparented to init. Subreapers (if a parent dies, reparent the children to this process, not init) solve the problem of grandchildren getting orphaned to init if the parent dies. Both excellent features for managing subtrees of processes, which is why they're useful for containers. Just not only containers.

But developers aren't going to take advantage of syscalls they have no idea that they exist, of course.

¹although I wish someone could tell me why pid_namespaces are root-only: what's the security risk of allowing unprivileged users to create pid_namespaces?

This is definitely true, but only as long as docker (or $container_runtime) remains lightweight enough that you can still use those independent parts on their own, compatibly with docker. The risk is that docker grows in complexity such that it creates new dependencies between these independent parts and therefore handicaps their power when used individually.

As an example, it's easy to create network namespaces and add routing rules, interfaces, packet forwarding logic, etc all by using `ip netns exec`. But there is no easy way to launch a docker container into an existing netns. You need to use docker's own network tooling or build your own network driver, which may be more complex than what you need. This strikes me as a code smell in docker.

> This is definitely true, but only as long as docker (or $container_runtime) remains lightweight enough that you can still use those independent parts on their own, compatibly with docker.

As someone who has exclusively used LXC containers (which Docker is/was initially built on), none of this applies to me.

Your issue is with Docker, the implementation, not containers as a concept.

Sometimes I feel HN needs to get its head out of Dockers butt and see that there's a world out here too. How many people here even know there are other container types at all? I'm often inclined to think none.

No really. Just once try real, raw containers without all that docker wrapping bloat. How everything works and is tied together is just clear as day and obvious at once. It's all simple and super refreshing.

The comment you replied to is clearly talking about Docker, and not containers in general. So I don't think the snark was warranted.

Docker is to containers what OAUth2.0 is to cryptography: a roll your own solution with a wide complexity.

Whereas jails/zones/VM have a complexity that is mutualized, docker have a feature of being more flexible which comes at the price that you may introduce more escape scenari.

As a result like in cryptography, Docker is kind of a roll your own crypto solution, secured by obfuscation that may if you don't have a lot of knowledge on the topic your own poison.

From this article you can derive 2 conclusions:

- docker is good for a big business having enough knowledge to devote a specialized team for handling the topic, because FEATURES

- jails/zones are more adapted for securing small business

Wasn't oauth 1 more a roll-your-own crypto solution? oauth 2 was created precisely to re-use more of what browsers already provide.

Not according to one of its main artisan.

https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-...

I think the biggest problem is most namespace functionality is root-only.

If I could create pid namespaces for my user-space apps, then every program I write forever would, as it's first step, launch into a pid namespace.

You can do that by creating an unprivileged user namespace. To be fair, this does break some things, but this is the key feature that makes rootless containers (in runC) possible.

Is it safe to turn that on in current kernels?

Well, I can't guarantee there are no kernel bugs in user namespaces, but the work that Eric and others have done to make user namespaces more secure does make me personally confident about running machines that have CONFIG_USERNS=y.

If you have SELinux, AppArmor, SMACK, Yama, or even good seccomp filters set up then I would classify it as "relatively" secure (most of the security issues in user namespaces have revolved around POSIX ACLs providing access where it doesn't make sense -- supplementing those ACLs with something like SELinux will eliminate entire classes of bugs).

Ultimately though, security is relative. Is a kernel that has CONFIG_USERNS=n more secure than one that doesn't? Yes (because it has less code running) but that doesn't mean that CONFIG_USERNS=y is insecure (it depends on what your paranoia level is dialed to).

I don't know if this addresses your question but...

Check out 'runc'. It is the tool Docker uses to start a Docker container. In that program, there is a '-u' option to start a container as whatever user ID (not username) you choose. Meaning you can start a container as a non-root user, although I don't know if that bubbles up as an option in the Docker public API, or can be set in a Dockerfile.

I'm not sure if it's what GP was talking about exactly, but there is USER instruction in Dockerfiles that lets you specify user to run as in the final image. Many Dockerfiles 'adduser' and then set USER to the newly created one.

(going from memory here, I believe this is accurate...)

When attaching to a running Foo container w/ runc, the default user is root. That's true even if the Foo container was started w/ the Foo user. Can a Dockerfile specify the default user when someone attaches to the running container?

Is it possible to create pid_namespaces for unprivileged users by wrapping pid_namespaces creation in a suid shell script that will take care of loading everithing using the current unprivileged user ?

Shell scripts can't be suid. But a binary wrapper could work.

If you enable user namespaces as well, then you don't need any of that. For example:

  [mrunal@local rootfs]$ id
  uid=1000(mrunal) gid=1000(mrunal) groups=1000(mrunal),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
  [mrunal@local rootfs]$ unshare -m -u -n -i -p -f --mount-proc -r sh
  sh-4.4# ps -ef
  UID        PID  PPID  C STIME TTY          TIME CMD
  root         1     0  0 09:42 pts/12   00:00:00 sh
  root         2     1  0 09:42 pts/12   00:00:00 ps -ef
  sh-4.4#

You can create a pid namespace if you also create a user namespace at the same time.

Reply on news.ycombinator.com