Technological advantages over Linux

Valeri Galtsev galtsev at kicp.uchicago.edu
Mon Feb 17 02:52:30 UTC 2020



> On Feb 16, 2020, at 3:32 PM, Ihor Antonov <ihor at antonovs.family> wrote:
> 

Thanks a lot, Ihor, for nice write-up! Gives those of us who are ignorant about Linux Docker as I am general view of things, and incentive to do our own reading.

Valeri

> On 2020-02-14 13:23, @lbutlr wrote:
>> On 14 Feb 2020, at 09:00, Valeri Galtsev <galtsev at kicp.uchicago.edu> wrote:
>>> In my book docker is really a disadvantage, not advantage, compared to FreeBSD jails
>> 
>> Dicker has the advantage of convenience and ease of installing/removing dockers, but you trade that for not only poor security, but another application layer between you and the service which itself has had numerous security issues.
> 
> 
> I've been reading this tread for a while, and now I can't help but to
> add my 2 cents:
> 
> I am long-time Linux sysadmin/devops and I work with "docker" on a daily
> basis. Reading this thread I got an impression that a lot of folks on
> BSD side have vague/wrong/incomplete understanding of Linux containers
> so I want to introduce more structure into this topic.
> 
> First off, "docker" is really a misnomer.  Nowadays linux world has a
> whole bunch of container tools: moby (former docker), podman, kata
> containers, cri-o etc. Not all of them are equal, some of them are complete
> user ecosystems, and some are just "bare" runtimes.  There was a tool
> named "docker" once with that name and the name really stuck, so people
> call things "docker" left and right. 
> 
> Second, there is no such thing as "linux containers" per se. There are 2
> kernel mechanisms: namespaces(allow isolating a process from a the rest
> of the system, like network namespace, user namespace, pid namespace
> etc) and cgroups(allow limit resource usage, like cpu, ram, bandwitdh).
> Combing various combinations of namespaces and cgroups you get
> "containers". On a low level tools like docker et al do is manipulate 
> namespaces and cgroups.
> 
> The design of namespaces is really the opposite to jails. With
> jails you start with a completely isolated environment and then you can
> add different capabilites if necessary. With namespaces you start with
> non-isolated process (process that shares namespaces with rest of the
> system) and you unshare namespaces one by one. (I can't compare resource
> limiiting part as I am not familiar with how it is done on FreeBSD)
> 
> It does not mean that namespaces are less secure than jails, it is a different
> design, more involved, probably harder to get righ, but also more
> flexible. 
> 
> Before docker it was very hard to use namespaces and cgroups for a
> regular linux user. There was no one "jail" command. There were only
> some system calls and scattered docs.(Well there was LXC, but not the
> point)
> What docker did(and was first to do it) is
> provided a very convenient and pretty complete ecosystem to manage
> namespaces and cgroups, including features like:
> - scripting container creation (aka Dockerfile) and sharing it as code
> - sharing compiled images 
> - Dockerhub is a centralized location for sharing images( it is just
>  glorified fileserver that hosts a lot of tar.gz + some indexing )
> - sharing/re-using iamges ( FROM clasue in Dockerfile )
> - nice CLI tool to manage containers and images
> 
> And it hid deeply notion of namespaces and cgroups, so regular joes were
> able to use it without learning what kernel mechanisms make it possible.
> Writing a dockerfile is not very different from writing a shell script
> really. It helped widespread adoption of the tool, but with this also
> created a lot of misconceptions too.
> 
> One can argue that "docker" is too bloated and is not really secure.
> 
> Yes, it is partially true: 
> - it makes some choices about how namespaces and cgroups are used, maybe
>  not the way YOU want. 
> - It is also a pretty big codebase in golang, that YOU did not audit and
>  which is not really necessary if you want to manage things manually
>  and customize to you needs. 
> - Yes, re-using images from the internet also introduces lots of risks. 
> - And yes, big army of regular joes who don't know how the tool works
>  allows misuse, miscofiguration etc.
> 
> But if you understand how it kerlnel works and when you understand your
> requirements it is becomes pretty easy to find a proper solutoin. 
> 
> 
> Now coming to jails. jail is pretty low level tool. It should not be
> compared to "docker". It can be compared to namespaces though.
> 
> I think it would be more productive to compare capabilities of ecosystems. 
> - Can you securely sandbox the process with jails or namespaces?
> - Can you easily script sanbox creation?
> - Can you share/re-use recepies or built images?
> - What tools provides more control and what provides more productivity
>  insread?
> - etc...
> 
> Where FreeBSD can improve IMHO is building ecosystem tools around jails. IOCage and
> Bastile are good projects, doing the right thing. But there are still
> little to none ways to re-use/share images and build recepies
> (AFAIK BasitleBSD is working in that direction). Some might argue that 
> BSD community does not need those - could be.
> 
>> I use docker for things that are not very important on machines that
>> are (relatively) unimportant. I would never use it on something like a
>> mail server or web server that has other people’s data on it.
> 
> Yes, use bubblewrap instead - really inspired by jails, minimal,
> oriented for maximum security. https://github.com/containers/bubblewrap 
> 
> 
> ------------
> Ihor Antonov
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"

++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++



More information about the freebsd-questions mailing list