4 ms·

I really want to try this, but I'm a little hesitant with the --privileged flag. Sounds like this is pretty much giving root access to the container? (https://s

I really want to try this, but I'm a little hesitant with the --privileged flag. Sounds like this is pretty much giving root access to the container? (https://stackoverflow.com/questions/36425230/privileged-containers-and-capabilities https://stackoverflow.com/questions/36425230/privileged-cont...) Could someone (or OP) enlighten me on what requires this flag? I thought the container would also get access to the anbox kernel modules that I have installed already.

AkihiroSuda 7y ago
The author of aind is here. --privileged is required for nesting an Anbox (LXC) inside Docker. But you don't need to worry too much because Anbox launches "unprivileged" LXC using user namespaces. You can confirm that all Android process are running as non-root users by executing `docker exec aind ps -ef`.
- ryanmjacobs 7y ago
  Ah gotcha, thanks for replying. I spun up a copy on a disposable machine and I was able to VNC into the container and everything. I like the window manager that's installed on it. Seems lightweight. Looking forward to exploring this tool!
mister_hn 7y ago
But docker runs still with root privileges (or your user must be in the docker group, which is equivalent to root - so is also in the official documentation explained)
- AkihiroSuda 7y ago
  Not always true since Docker 19.03: https://docs.docker.com/engine/security/rootless/ https://docs.docker.com/engine/security/rootless/ Probably aind doesn't work with rootless Docker currently mostly because of squashfs stuff, but I believe we can workaround that relatively easily.
- ryanmjacobs 7y ago
  Right I get that, it's because the docker daemon needs root access to do its management stuff. But as far as running random "bad things" off docker hub, I always assume it's going to be fenced off. Like by default, the containers cannot read external files or open up host ports, etc. But with --privileged I guess it can do anything. I'm a big fan of people supplying pre-built docker images because it lets me try out their software in what I assume to be a sandbox. I'm a little less wary when it comes to docker -- almost to the point of being nonchalant, running random images willy-nilly without digging into the source code even a tiny bit. Granted, that behavior is probably gonna bite me in the ass one day. But it's definitely better than the `curl http://example.com http://example.com | bash -` and `sudo make install` patterns. Whenever I see someone's instructions telling me to use `docker --network=host` or `docker --privileged`, I can't help but panic a little... "Am I going to regret running this developer's code as root on my machine?" A little justification from the OP eases my mind, that's all. Which he did :)
  - londons_explore 7y ago
    I think you're putting too much faith in the security of docker... It is only superficially secure, and any real evil software can break out of it since the attack surface is huuuge (every loaded kernel driver).
    - rtempaccount1 7y ago
      Docker has a number of security layers that can make breakout more challenging, specifically dropped capabilities, a seccomp filter and (on debian/ubuntu) an AppArmor profile installed. I wouldn't agree that it's trivially possible to breakout of a default configured Docker container, not every attacker is packing a Linux Privesc 0-day and the knowledge to use it.
    - fulafel 7y ago
      It's telling that user namespaces (remapping uid 0 to another hodt uid) aren't used by default.
  - containrh4x0r 7y ago
- aioprisan 7y ago
  Not necessary anymore, you just need to enable overlayfs for unprivileged users https://kernel.ubuntu.com/git/ubuntu/ubuntu-bionic.git/commit/fs/overlayfs?id=3b7da90f28fe1ed4b79ef2d994c81efbc58f1144 https://kernel.ubuntu.com/git/ubuntu/ubuntu-bionic.git/commi...
  - AkihiroSuda 6y ago
    overlayfs isn't necessary either :)
- rtempaccount1 7y ago
  The user who runs the docker command can indeed always get root (with a default install, assuming you're not using rootless) but the process inside the container isn't going to necessarily breakout. That's why --privileged is generally a bad idea, unless you really need it, as it removes the isolation that Docker adds.

AkihiroSuda 7y ago

The author of aind is here. --privileged is required for nesting an Anbox (LXC) inside Docker. But you don't need to worry too much because Anbox launches "unprivileged" LXC using user namespaces. You can confirm that all Android process are running as non-root users by executing `docker exec aind ps -ef`.

ryanmjacobs 7y ago
Ah gotcha, thanks for replying. I spun up a copy on a disposable machine and I was able to VNC into the container and everything. I like the window manager that's installed on it. Seems lightweight. Looking forward to exploring this tool!

mister_hn 7y ago

But docker runs still with root privileges (or your user must be in the docker group, which is equivalent to root - so is also in the official documentation explained)

AkihiroSuda 7y ago
Not always true since Docker 19.03: https://docs.docker.com/engine/security/rootless/ https://docs.docker.com/engine/security/rootless/ Probably aind doesn't work with rootless Docker currently mostly because of squashfs stuff, but I believe we can workaround that relatively easily.
ryanmjacobs 7y ago
Right I get that, it's because the docker daemon needs root access to do its management stuff. But as far as running random "bad things" off docker hub, I always assume it's going to be fenced off. Like by default, the containers cannot read external files or open up host ports, etc. But with --privileged I guess it can do anything. I'm a big fan of people supplying pre-built docker images because it lets me try out their software in what I assume to be a sandbox. I'm a little less wary when it comes to docker -- almost to the point of being nonchalant, running random images willy-nilly without digging into the source code even a tiny bit. Granted, that behavior is probably gonna bite me in the ass one day. But it's definitely better than the `curl http://example.com http://example.com | bash -` and `sudo make install` patterns. Whenever I see someone's instructions telling me to use `docker --network=host` or `docker --privileged`, I can't help but panic a little... "Am I going to regret running this developer's code as root on my machine?" A little justification from the OP eases my mind, that's all. Which he did :)
- londons_explore 7y ago
  I think you're putting too much faith in the security of docker... It is only superficially secure, and any real evil software can break out of it since the attack surface is huuuge (every loaded kernel driver).
  - rtempaccount1 7y ago
    Docker has a number of security layers that can make breakout more challenging, specifically dropped capabilities, a seccomp filter and (on debian/ubuntu) an AppArmor profile installed. I wouldn't agree that it's trivially possible to breakout of a default configured Docker container, not every attacker is packing a Linux Privesc 0-day and the knowledge to use it.
  - fulafel 7y ago
    It's telling that user namespaces (remapping uid 0 to another hodt uid) aren't used by default.
- containrh4x0r 7y ago
aioprisan 7y ago
Not necessary anymore, you just need to enable overlayfs for unprivileged users https://kernel.ubuntu.com/git/ubuntu/ubuntu-bionic.git/commit/fs/overlayfs?id=3b7da90f28fe1ed4b79ef2d994c81efbc58f1144 https://kernel.ubuntu.com/git/ubuntu/ubuntu-bionic.git/commi...
- AkihiroSuda 6y ago
  overlayfs isn't necessary either :)
rtempaccount1 7y ago
The user who runs the docker command can indeed always get root (with a default install, assuming you're not using rootless) but the process inside the container isn't going to necessarily breakout. That's why --privileged is generally a bad idea, unless you really need it, as it removes the isolation that Docker adds.