4 ms·

Any security folks have some specific practical examples of how running processes as root inside the container is dangerous? I understand how root in the contai

Any security folks have some specific practical examples of how running processes as root inside the container is dangerous? I understand how root in the container mapping to root on the host is risky (this is what user namespaces are for) but I don't have enough experience to know why it matters inside the container.

darkr 11y ago
Though things have improved considerably a while back with docker dropping most capabilities before starting a container, but without user namespacing on a shared kernel, ultimately root in the container == root in the host machine. More specifically, uid 0 on the container == uid 0 on the host, so if container breakout occurs then you have root on the host. As you mention, user namespaces and remapping the root user should solve this issue, but initial support for this was only released 7 days ago in docker 1.10.2 > https://github.com/docker/docker/commit/ed9434c5bb64f49db442027e5e748bfbb46d0a0a https://github.com/docker/docker/commit/ed9434c5bb64f49db442... [edit]: Preliminary support for user namespaces was added in 1.10, above commit is addressing a bug in userns support.
xorcist 11y ago
Apart from that Docker doesn't really utilize user namespaces until recently, user namespaces are tricky. There have historically been buts and ifs involved. Don't rely on it unless you really understand it! But why would you want to run things as root anyway? You probably didn't before Docker, so why do it now? With Docker, there's even less reason to muck about with capabilities for binding low ports etc. It's absolutely an unnecessary risk to take.
- fpoling 11y ago
  If one use host volumes, Docker has no way to setup them in a way that are usable for non-root container. There are workarounds, but running as root is a simplest thing to do that I think many follow.
  - xorcist 11y ago
    That is a strange thing to say. If a mounted volume is reason for you to do away with permissions, you're doing it wrong.
gtrevorjay 11y ago
Given the possibility of a container escape, it's far better for the escapee to find himself on the outside as a normal user. Just like with kernel exploits, most escapes rely on access to esoteric, complicated, or poorly understood devices or functions. Obviously, there are fewer of those in userspace. Imagine, for example, an escape that required arbitrary network control. That would be much harder to pull off (if not impossible) from userspace. There have been and will continue to be parts of the kernel hard-coded to respect UID 0. Until these are all found and fixed (likely many years from now) using usernamespaces to remap root will not provide all the safety one might assume. It is super handy for other users though. Full disclosure - I am both a hatter and a sec guy.
- yAnonymous 11y ago
  The attacker can install a keylogger as normal user and then wait for the sudo password. How much better is that, really?
  - tokenizerrr 11y ago
    How would a normal user go about installing this system-wde keylogger?
    - NoGravitas 11y ago
      It wouldn't be system-wide. You'd need to compromise an interactive user account, install and run the keylogger as them, and wait for them to su or sudo. So it's a means of escalating privileges from a regular user account.
      - tokenizerrr 11y ago
        Right, and your daemons use sub-1000 UIDs and user UIDs start at 1000. In Debian, at least. Other distros have other starting points, but the concept remains the same.
  - gtrevorjay 11y ago
justincormack 11y ago
You can obviate almost all the issues by running docker with --drop-cap all to drop all capabilities. You still share the uid, but with the default seccomp policy blocking ptrace as well it is pretty secure. Obviously running as a user as well is better.

darkr 11y ago

Though things have improved considerably a while back with docker dropping most capabilities before starting a container, but without user namespacing on a shared kernel, ultimately root in the container == root in the host machine. More specifically, uid 0 on the container == uid 0 on the host, so if container breakout occurs then you have root on the host. As you mention, user namespaces and remapping the root user should solve this issue, but initial support for this was only released 7 days ago in docker 1.10.2 > https://github.com/docker/docker/commit/ed9434c5bb64f49db442027e5e748bfbb46d0a0a https://github.com/docker/docker/commit/ed9434c5bb64f49db442... [edit]: Preliminary support for user namespaces was added in 1.10, above commit is addressing a bug in userns support.

xorcist 11y ago

Apart from that Docker doesn't really utilize user namespaces until recently, user namespaces are tricky. There have historically been buts and ifs involved. Don't rely on it unless you really understand it! But why would you want to run things as root anyway? You probably didn't before Docker, so why do it now? With Docker, there's even less reason to muck about with capabilities for binding low ports etc. It's absolutely an unnecessary risk to take.

fpoling 11y ago
If one use host volumes, Docker has no way to setup them in a way that are usable for non-root container. There are workarounds, but running as root is a simplest thing to do that I think many follow.
- xorcist 11y ago
  That is a strange thing to say. If a mounted volume is reason for you to do away with permissions, you're doing it wrong.

gtrevorjay 11y ago

Given the possibility of a container escape, it's far better for the escapee to find himself on the outside as a normal user. Just like with kernel exploits, most escapes rely on access to esoteric, complicated, or poorly understood devices or functions. Obviously, there are fewer of those in userspace. Imagine, for example, an escape that required arbitrary network control. That would be much harder to pull off (if not impossible) from userspace. There have been and will continue to be parts of the kernel hard-coded to respect UID 0. Until these are all found and fixed (likely many years from now) using usernamespaces to remap root will not provide all the safety one might assume. It is super handy for other users though. Full disclosure - I am both a hatter and a sec guy.

yAnonymous 11y ago
The attacker can install a keylogger as normal user and then wait for the sudo password. How much better is that, really?
- tokenizerrr 11y ago
  How would a normal user go about installing this system-wde keylogger?
  - NoGravitas 11y ago
    It wouldn't be system-wide. You'd need to compromise an interactive user account, install and run the keylogger as them, and wait for them to su or sudo. So it's a means of escalating privileges from a regular user account.
    - tokenizerrr 11y ago
      Right, and your daemons use sub-1000 UIDs and user UIDs start at 1000. In Debian, at least. Other distros have other starting points, but the concept remains the same.
- gtrevorjay 11y ago

justincormack 11y ago

You can obviate almost all the issues by running docker with --drop-cap all to drop all capabilities. You still share the uid, but with the default seccomp policy blocking ptrace as well it is pretty secure. Obviously running as a user as well is better.