[split] What's wrong with Docker?

[pjp]

A bug, sure. How is a bug something incredible or malware?
_________________
Quis separabit? Quo animo?

[1clue]

[erm67]

https://blog.aquasec.com/a-brief-history-of-containers-from-1970s-chroot-to-docker-2016

Basically the first OS to provide access segregation to computer resources was FreeBSD at the beginning of the millenium, basically *BSD freaks were popping out in every forum bragging about how cool were their jails and how superior was their OS. The linux port didn't worked well and the replacement (developed by google and called cgroups) wasn't also very succesfull despite being superior to BSD jails, in part because some linux user hate innovations, it was only when docker appeared that containers boomed and become ubiquitous for linux. Recently, with the appearance of Docker for Windows and Microsoft's dotnet for alpine, linux become just a mid layer to run safely c# programs on a Windows Server.


cgroups only provide separated kernel namespaces to processes, so different processes only see a portion of resources.

PS docker keeps pulling binaries for the wrong architecture, kubler was a lot more funny, it found out that there were no binary images available for my arch and than downloaded a binary gentoo stage3 for X86_64 attempting to bootstrap an image.
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia

My fediverse account: @erm67@erm67.dynu.net

[erm67]

[erm67]

This is what I mean:

[sligo]

[sligo]

Just figured you've posted more earlier. Sorry, for not following this right away.

I am not so much into Docker as of yet. At least not to follow your extended writings about Docker with LTO or aarch64. As i said in an earlier post, i've only started some months ago. Does Alpine allow LTO with shared binary libraries over multiple containers? I think the alpine guys doing a really good job with their OS. So far it only seems that if you're about to use Gentoo within your images, you're heading into a huge pile of work. The tutorials with Crossdev in Gentoo Wiki are far from easy in the long run.

[erm67]

Sorry if I confused you, I was just complaining that having to use a full stage3 as base docker imager, maybe setup by kubler, is not optimal since other OS provide smaller and more fine grained images. The amd64 stage3 is certainly not a lot smaller than the ARM64 one
That's not a bug but a feature of course.
The aarch64 group at docker, now called (more correctly) arm64v8 is doing a great job, I seriously doubt they crosscompile anything however, and most base images are available:
https://hub.docker.com/u/arm64v8
no more crosscompiling for some years now, the crosscompiling pages might be useful for IOT thought ...

I guess I will have to hack a bit more kubler scripts Where the part where it reduces the stage3 size?
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia

My fediverse account: @erm67@erm67.dynu.net

[sligo]

[ct85711]

From my short experience with docker, I still feel it needs more polishing. Some of the parts that I feel isn't working as it should could very well be from my limited experience. One part is with docker swarms (clustering), while it seems to be a good thing. One big issue I noticed, is support of mixing windows and linux native hosts into the swarm is frankly like badly done, hastily, bandaged thing (this is a known issue upstream). The other part, that I am disappointed on, is more of setting preferences on which machine in the cluster to use is lacking. A good example, is more of a small cluster with a few machines (of different specs), of some that have little usage, ok ram, and low storage, to a machine that have high speed cpu & large amount of memory, to another that is slower but good amount of memory and tons of free space. Ideally, there should be some configuration to set preference of machines for different tasks.

The other side, for my case usages is more on the development side. From what I have been seeing, docker containers seem to be more focused on running finished products. However, if you want to develop within the container (not easily setup, especially adding in remote development, it is possible), you can/will be constantly fighting with docker and watching it eat through your storage space fast. In my case, I decided to do some simple java development but the key part is the jdk is only in the docker container (not the development system). Trying to get all of the output or debugging/error messages is like hitting your head against the wall. Of course there is the side if you want to recompile the project, ends up making a image. Now there is a flag to have docker to automatically cleanup afterwards, but you get into an issue of any would be messages are voided (it seems the messages is only available while the image is there running).

Another part, that limits the usefulness is the part that having a gui interface for stuff in the container is pretty much unsupported. You should possibly get something taped together to do it, but it primarily is using either vnc/rdp (greatly adding to the image size).

The last part from what I have seen, is more of on the container side. The concept of the containers is more of layering the containers over each other building up the virtual machine final setup. My complaint is more of it doesn't allow you to use your base system as the foundation. Instead, you pretty much have to use some OS image as the base, and layer the containers off that; adding more space usage that could have easily been saved if you are using a native arch container.

[erm67]

[edannenberg]

disclaimer: I'm the author of Kubler.

I realized pretty early that Docker is not yet another short lived hyped product, but a true paradigm switch for virtualization. I'm still hesitant to run Docker on public facing production critical servers, but it has been quite the boon for our internal services and development environments. Couldn't live without it any more.

Gentoo based Docker images are tricky though as there is no official Gentoo binary package server, so trying to follow the standard Docker way pretty much requires a full gcc toolchain and portage tree, resulting in very large Docker images. It's not a good fit from that perspective, on the other hand the flexibility and control Portage delivers is pretty much perfect for Docker images.

Kubler (formerly gentoo-bb) was my attempt to solve this dilemma. It essentially enabled nested Docker builds long before Docker itself added support for this. In theory nowadays you can do the following in your Dockerfiles:

[erm67]

Sorry if I talked bad of your program, it is great really, my only issue is that I use a arm64 gentoo and was trying to use kobler to generate some fine docker images. Please be so kind and let users choose the what stage3 use to bootstrap from the command line .... sometimes even the most perfect logic fails
I was able to convince it to download the correct (and only) stage3 available for my arch but unfortunately, as you can see here:
wget http://distfiles.gentoo.org/experimental/arm64/stage3-arm64-20190115.tar.bz2.DIGESTS
the digest file contains the right hash for the file but the wrong file name, this is probably common with less cared for archs like arm64, but makes your script fail.

I fixed those 2 small problems, added a

[edannenberg]

[erm67]

[sligo]

[erm67]

This is probably a problem:
https://bugs.gentoo.org/239114#c10
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia

My fediverse account: @erm67@erm67.dynu.net

[sligo]

[edannenberg]

[erm67]

[1clue]

Sorry for resurrecting a recently-dead topic, but the runc vulnerability (which is pretty much patched) illustrates what's wrong with containers in general.

https://www.openwall.com/lists/oss-security/2019/02/11/2

This is a security hole in runc, which is used by docker, kubernetes, containerd, cri-o, etc. It allows a script in a guest to break out of the guest and run as root in the host. It's pretty much the worst case security flaw in any virtualization scheme. And yes, I understand that containers are not really virtualization, but they're a sort of middle ground.

While it's bad enough that a guest can infect the host as root, what's worse in this case is that the flaw is in a single piece of code which is used by so many container schemes. We have the electronic equivalent of a single species which can be wiped out by a single plague.

In this case the fix was known almost immediately, but it's feasible that a flaw with similar exposure may be known by the black hats much earlier than it's known by the white hats, and might be exploited widely in the wild.

[r7l]

I've started using Docker to replace some virtual machines i was using prior but i don't use it as a layer of security. I really like containers for what they are. A tool to minimize the amount of setup time on each system or on migration. But i am trying to run everything like if it would be installed on the host system and don't give privileges for Docker to anyone. It's a tool for root only.

[1clue]

It doesn't matter if you use docker as a security layer. If you run malicious code inside docker and something like the runc bug is making your system vulnerable, then you're owned. Not just the container but your whole host.

[Hu]

The cited bug report involves running malicious code as root inside the container. If the attacker is not allowed root inside the container, then this problem does not apply. If the attacker is allowed root inside the container, then there are probably other ways to subvert the system. The classic system security design has long held that confining root is not a worthwhile exercise. Some people are trying to change that, but it is a major project.

There is always the risk that there is an even worse vulnerability that would allow an unprivileged user in the container to escalate to root, but that is why you implement security boundaries using well-tested and well-understood primitives. Strictly limit what code can be run. Limit the privileges that the confined program enjoys to the minimum required for it to do its job. Limit its ability to receive untrusted input, so that an attacker is not given a chance to confuse a privileged program.

If Docker is used purely as an alternative to unpacking a tarball and chroot'ing into it, with no expectation that it will provide a security boundary, then it is no more dangerous than a manual unpack. People want to treat containers as this magic solution that provides all the supposed security benefits of full hardware virtualization and all the performance benefits of running everything on a single system. That's a misguided view, but it's not unique to Docker.

[r7l]

I've found this yesterday: https://snyk.io/blog/top-ten-most-popular-docker-images-each-contain-at-least-30-vulnerabilities

It does not surprise me in the slightest. This scenario was pretty much what i was expecting when i heard about Docker and saw the setup of their repository (Docker Hub). This is exactly why i am highly skeptical about containers myself. Most people seem to be ok with the mentality to not really care for the source or state of their included software.