5 ms·

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 o

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?

chatmasta 10y ago
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.
- josteink 10y ago
  > 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.
  - vosper 10y ago
    The comment you replied to is clearly talking about Docker, and not containers in general. So I don't think the snark was warranted.
  - deleted 10y ago
    [deleted]
XorNot 10y ago
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.
- cyphar 10y ago
  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.
  - yrro 10y ago
    Is it safe to turn that on in current kernels?
    - cyphar 10y ago
      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).
- amorphid 10y ago
  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.
mingodad 10y ago
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 ?
- yjftsjthsd-h 10y ago
  Shell scripts can't be suid. But a binary wrapper could work.
- mrunalp 10y ago
  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#
julie1 10y ago
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
- nailer 10y ago
  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.
  - julie1 10y ago
    Not according to one of its main artisan. https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/ https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-...
wlamartin 10y ago
You can create a pid namespace if you also create a user namespace at the same time.

chatmasta 10y ago

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.

josteink 10y ago
> 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.
- vosper 10y ago
  The comment you replied to is clearly talking about Docker, and not containers in general. So I don't think the snark was warranted.
- deleted 10y ago
  [deleted]

XorNot 10y ago

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.

cyphar 10y ago
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.
- yrro 10y ago
  Is it safe to turn that on in current kernels?
  - cyphar 10y ago
    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).
amorphid 10y ago
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.

mingodad 10y ago

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 ?

yjftsjthsd-h 10y ago
Shell scripts can't be suid. But a binary wrapper could work.
mrunalp 10y ago
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#

julie1 10y ago

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

nailer 10y ago
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.
- julie1 10y ago
  Not according to one of its main artisan. https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/ https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-...

wlamartin 10y ago

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