![]() ![]() ![]() That is all the contents in the post is about. Let me put it this way: You could implement the described approach as an ordinary bash script which gets executed as root (on the host), dynamically configures iptables rules, switches to a non-privileged user and executes the application. Right, this is the major misunderstanding of the described approach. That is nothing we have to really discuss.Īccording to his approach, anyone with docker group permission can do some serious damage as root and bypass his firewall rule defined inside the container. Running containers as root is bad in general. I doubt that you have read the blog post in much detail which is fine, but a little bit of restraint would be appropriate IMHO. There is no need for being harsh when arguing from a different perspective and (especially) when having a different use case in mind. Like comment: Like comment: 1 likeįirst of all, I don't like the tone of your comments. So I wrote a simple PoC in my repo: /rickyzhang82/demo-misco. Because neither of us listened to each other. This is very important to keep our Internet safe. I'm done with my explanation.īut I hope you should remove this blog and stop misleading others. But it doesn't change the fact that your container still run as root.Īgain, if you don't get it, it is fine. Thirdly, you don't need to say you switch account. Do whatever read/write on your hardware/software device freely. Anyone with docker group permission can go inside your container. Secondly, your container still runs as root and launch with -privileged options. Then you don't need to be user root in Dockerfile. You don't have to do it inside the container. But I want to state that your idea is wrong.įirst, do iptables change in the host. Neither of us are native English speaker. Let's have a look at the actual solution. The ENTRYPOINT script gets executed when the container starts, defines the iptables rules and starts the given application as the configured non-privileged user afterwards.Provisioning of a base image which ships with a non-privileged user and an ENTRYPOINT script.Meh!Īfter implementing some test probes, I settled with the following solution: "A privileged user is necessary for restricting network traffic." was my first thought which conflicts with the third acceptance criteria. The application within the container should run as a non-privileged user.The container should block in- and outbound traffic from and to all other networks.The container should accept in- and outbound traffic from and to a known network.Before I headed straight into tinkering, I created the following acceptance criteria: I thought about that problem today and want to share my approach with you. But what if the module wants to phone home?” Indeed, that helps when the evil module tries to mess up with your filesystem or other host related aspects. "But I'm isolating everything in a Docker container at runtime!", you might say. A dependency that wants to do something evil – a malware. Imagine a scenario in which you might have a stinky module deep in your dependency graph. ![]()
0 Comments
Leave a Reply. |